At very rare situations, we won't be able to get the top level window
context. Perhaps, it's the case that the window has been detached from
the dom tree while checking the permission. So, we need to check the top
level window context before we really use it.
Differential Revision: https://phabricator.services.mozilla.com/D85978
This testcase has:
top-level: mochi.test
1st-level: host (depend on the value in the test data)
2nd-level: mochi.test
This test run tests in the 2nd-level iframe, which is first-party with
respect to the top-level according to the new change.
The test is re-written to run tests in both 1st-level iframe and
2nd-level iframes.
Differential Revision: https://phabricator.services.mozilla.com/D86717
A lot of entries in the extended jump table were never used because they were for
jumps/calls to other addresses in the executable memory (JitCodes or trampolines).
This patch takes advantage of the contiguous 2 GB executable code buffer: we know
any address in this buffer can always be jumped to without needing an extended jump
table. This also lets us simplify the jump relocation code more.
With Fission coming soon, max 2 GB JIT code per process will hopefully be sufficient.
Depends on D86374
Differential Revision: https://phabricator.services.mozilla.com/D86375
All pending jumps then have a known (non-null) target, so replace an if-statement
with an assertion.
Other platforms don't define addPatchableJump.
Depends on D86368
Differential Revision: https://phabricator.services.mozilla.com/D86370
The jump instruction itself is sufficient to get the address from the extended jump
table. This has been 'dead' code on x64 since the code landed in 2011. ARM64 copied it.
Differential Revision: https://phabricator.services.mozilla.com/D86368
This is strictly better and more flexible, but can change specificity so
have a pref in case it causes trouble. I doubt it will though, the
specificity rules of :is() make more sense, and my gut feeling is that
:-moz-any is not very used on the wild.
Make it early-beta-or-earlier for now to minimize risk, once this is on
nightly for a bit we can enable it everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D86696
This adds correct NaN handling to the SIMD f32x4/f64x2.min/max code.
This is a bit of a horror show actually. There is a reasonable fast
path if neither operand contains a NaN, but the slow path to handle
NaN is long and there's a lot of code. (This is an Intel-only
problem, on other architectures there's a direct mapping.)
It is possible the slow-path code could be somewhat improved (both
speed and size) by using at least three BLEND instructions, but I
consider that a possible optimization that needs investigation and
empirical backing. Meanwhile, we can land this plausible code.
Differential Revision: https://phabricator.services.mozilla.com/D86318
Wasm treats signalling and quiet NaN the same - as quiet NaN. Where
convenient, test also signalling NaN. This is complicated by JS not
being able to represent signalling NaN directly.
Differential Revision: https://phabricator.services.mozilla.com/D86317
These test cases were generated by a script from some of the
preliminary test cases in the SIMD spec repository, taking into
account the specific NaN types asked for.
These tests are temporary: once we have proper generated test cases
from the spec repository, these will no longer be needed.
Differential Revision: https://phabricator.services.mozilla.com/D86316
Two bugs:
- an accidental redefinition of the 'eq' predicate resulted in the
'permute' function not working and thus in us not testing floating
point operations for NaN, Infinity, and some other interesting
values.
- the previous bug masked the fact that the max and min operations for
floating point were not implemented properly; they have to handle
NaN specially.
Differential Revision: https://phabricator.services.mozilla.com/D86315
Implement some of the experimental SIMD opcodes that are supported by
all of V8, LLVM, and Binaryen, for maximum compatibility with test
content we might be exposed to. Most/all of these will probably make
it into the spec, as they lead to substantial speedups in some
programs, and they are deterministic.
For spec and cpu mapping details, see:
https://github.com/WebAssembly/simd/pull/122 (pmax/pmin)
https://github.com/WebAssembly/simd/pull/232 (rounding)
https://github.com/WebAssembly/simd/pull/127 (dot product)
https://github.com/WebAssembly/simd/pull/237 (load zero)
The wasm bytecode values used here come from the binaryen changes that
are linked from those tickets, that's the best documentation right
now. Current binaryen opcode mappings are here:
https://github.com/WebAssembly/binaryen/blob/master/src/wasm-binary.h
Also: Drive-by fix for signatures of vroundss and vroundsd, these are
unary operations and should follow the conventions for these with
src/dest arguments, not src0/src1/dest.
Also: Drive-by fix to add variants of vmovss and vmovsd on x64 that
take Operand source and FloatRegister destination.
Differential Revision: https://phabricator.services.mozilla.com/D85982
Before this change the styling of the inputs in the Debugger was inconsistent. This patch addresses this issue by:
1. Modifying the appearance of the placeholder text by setting its `color` to `--theme-text-color-alt` and its `opacity` to `1`. This ensures that the placeholder text has a contrast ratio of 4.74 when paired with a white background and passes the 4.5:1 contrast requirement of WCAG.
2. Modifying the height of the inputs in the Primary and Secondary Panes so that they are all `24px`.
{F2406940}
Differential Revision: https://phabricator.services.mozilla.com/D85630
This interface extends nsIDNSRecord and makes the DNS code more extensible
by allowing us to support more record types.
This change does require the consumer to be aware of the type they requested
and to QueryInterface to either nsIDNSAddrRecord for regular IP lookups,
or to nsIDNSByTypeRecord for other kinds of lookups.
Differential Revision: https://phabricator.services.mozilla.com/D86177
This patch adds the nsIDNSResolverInfo interface which is used to hold
information about the resolver to be used in a DNS resolution.
We use this to merge all of the *WithTRRServer resolve functions into one.
Passing a resolver info will use that object when appropriate. No resolver
info means that we default to using the system resolver, or the default TRR
resolver.
This patch also converts the RESOLVE_TYPE_* flags into a cenum and adds
the resolveType as a parameter to asyncResolve thus removing the need
to have asyncResolveByType methods.
Differential Revision: https://phabricator.services.mozilla.com/D86176
We do this analogously to how PanGestureInput does it except that the delta's that we compute mLineOrPageDeltaY from are computed by us instead of provided to us.
mLineOrPageDeltaY being non-zero is what EventStateManager::DispatchLegacyMouseScrollEvents uses to decide to send legacy mouse events, so we need to populate it to get those legacy events to send.
This fix is Windows only on purpose as pinches on macOS don't seem to send wheel events (Windows sends ctrl+wheel). When Linux gets implemented it will need to be determined what to do.
Differential Revision: https://phabricator.services.mozilla.com/D86495
The MediaChangeMonitor would always use the selected PDM in order to create a decoder; this only worked if the Decode method returned an error if the format was unsupported and this is how the WMF decoder worked.
However, the AppleVTDecoder fails on creation instead.
Now that the VP9 profile is known at creation time, we should move the WMF decoder to do the same.
Differential Revision: https://phabricator.services.mozilla.com/D86545
To create a VP9 decoder, the VideoToolbox requires a vppC atom similar to how the H264 one requires an avcC one.
That information is typically not available in the webm container and is found in the VP9 bytestream with each keyframe.
In order to minimise the extent of the changes, we move the task of retrieving the vpcC content in the MediaChangeMonitor as it already performs a similar task in order to detect if the format has changed.
The VPXChangeMonitor will now only instantiate a VP9 decoder once a keyframe is seen.
Differential Revision: https://phabricator.services.mozilla.com/D86544
The mac VP9 decoder; like the H264 requires some out of band settings before it can be created.
This information is only found in the mp4 container, we can create it from the vp9 bitstream.
For now we ignore the colors information as we can't handle it properly yet in our compositor and this is not available in the bytestream.
Differential Revision: https://phabricator.services.mozilla.com/D86542
I realized this was broken when fixing browser_restoreEmptyInput.js. That test opens Top Sites and keys down to the first result, which is the Amazon search shortcut. It checks that the Urlbar has a value in it. The test broke since token aliases were no longer filling the Urlbar.
Differential Revision: https://phabricator.services.mozilla.com/D86765
_doesEventClearPrevFieldValue is still an imperfect heuristic, as there are cases where the non-empty value of a confirm password field is replaced (with inputType of 'insertReplacementText') where it will incorrectly return false:
* Autocorrect
* User accepts a spell checker recommendation
* User replaces the generated password with a saved password from the context menu
All are remote scenarios. E.g. the last one would require:
* a page with a confirm password field
* the password manager to correctly detect the confirm password field
* the user to have previously saved logins for the page
* the user to generate a password
* the user to replace the generated password with a saved login password without first backspacing/deleting the generated password.
* Typically pages with confirm password fields imply the field should have a new password value, so it is unlikely that they would want to fill the confirm field with an existing password.
The consequences of this current heuristic incorrectly returning false in these remote scenarios are that edits to this field would continue to be autosaved on "change" events. We have deemed this an acceptable concession to improve this _doesEventClearPrevFieldValue heuristic in the absence of other viable alternatives to explicitly know the previous value of the input field.
Differential Revision: https://phabricator.services.mozilla.com/D85900
Tim Huang
Dimi Lee
Cosmin Sabou
Mirko Brodesser
Jan de Mooij
Emilio Cobos Álvarez
Mike Hommey
Lars T Hansen
Bogdan Tara
Kyle Knaggs
Valentin Gosu
undef1nd
Martin Stransky
Timothy Nikkel
Sylvestre Ledru
Jean-Yves Avenard
Mihai Alexandru Michis
Harry Twyford
Brindusan Cristian
Ryan VanderMeulen
Bianca Danforth
Emma Malysz