It is not quite clear to me if GetBrowsingContext can ever be null that is why I opened Bug 1604040.
Differential Revision: https://phabricator.services.mozilla.com/D57247
--HG--
extra : moz-landing-system : lando
Calls around `nsContentUtils::ComparePoints` will be cleaned-up in a
separate commit.
Differential Revision: https://phabricator.services.mozilla.com/D54458
--HG--
extra : moz-landing-system : lando
Once `RawRangeBoundary::Offset()` is removed, callers are forced to pass
a filter to `Offset()`. Making it less likely for new callers to
undeliberately retrieve invalid values.
`RawRangeBoundary::Offset()` is removed in separate commit, once all
callers adapted.
Differential Revision: https://phabricator.services.mozilla.com/D54456
--HG--
extra : moz-landing-system : lando
Usually we update mBounds from OnSizeAllocate() which is called
by Gtk when mContainer changes its actual size.
However we need to set mBounds in advance at Resize() as JS
code expect immediate window size change. When Resize() is called between
SetSizeMode() calls (which maximize/unmaximize the window) we can miss
OnSizeAllocate() Gtk call as actual mContainer size may not change
from Gtk perspective and we end up with incorrect mBounds.
To compensate it call OnSizeAllocate() explicitly also
from OnConfigureEvent().
Differential Revision: https://phabricator.services.mozilla.com/D55941
--HG--
extra : moz-landing-system : lando
Lift the code that checks JS values against reference types (and boxes anyref)
from all the places where it is repeated into a common function.
Clean up some code that assumes that the only reference types are anyref
and funcref.
Differential Revision: https://phabricator.services.mozilla.com/D56971
--HG--
extra : moz-landing-system : lando
The return value of a wasm builtin call may just be used to check if the
runtime caused an internal error (e.g. oom). There are assertions in code that
the return value of wasm builtins not supposed to return a wasm value actually
do this, so we shouldn't return values that are only internally used.
This could have been done a simpler way by only having "FailureMode::NotZero"
imply "do not return", but this is more future-proof like this: shared memory
/ atomics builtins both check the internal value *and* return it to the wasm
value stack.
Differential Revision: https://phabricator.services.mozilla.com/D57125
--HG--
extra : moz-landing-system : lando
This way we get proper JIT tiering. It will also make it possible to
assert all backward jumps are to a JSOP_LOOPHEAD.
Differential Revision: https://phabricator.services.mozilla.com/D56715
--HG--
extra : moz-landing-system : lando
For paragraphs, divs, spans, etc., a11y focus on Android goes to text leaf Accessibles, rather than to the HyperTextAccessible container.
This does make sense, as these containers frequently embed other content, so the text needs to be reachable as a separate item.
However, previously, performing text navigation on these text leaf Accessibles returned the HyperTextAccessible parent.
This isn't supported by Talkback, and even if it were, it causes other problems; e.g. a11y focus being lost if the user was focused on a child other than the first child of such a container.
Therefore, if text navigation was performed on a text leaf Accessible, we now return a result within the text leaf Accessible if possible, rather than the HyperTextAccessible.
1. Make AccessibleWrap::GetTextContents support text leaf Accessibles (for both local and remote proxied Accessibles).
This is used when providing text for text traversal events.
2. When navigating text on Android, we use Pivot::Next/PrevText.
However, this will always return a HyperTextAccessible, even when starting on a text leaf.
Therefore, if the result from Pivot::Next/prevText resides entirely within the same text leaf, translate the offsets from the HyperTextAccessible so they're relative to the text leaf and return the text leaf.
3. Pivot::Next/PrevText already supported starting from a text leaf Accessible.
However, they ignored the offsets, which meant that navigating from a text leaf would always navigate to the start/end of the text leaf.
Now, if a text leaf is passed to Pivot::Next/PrevText, the offsets (if specified) are translated to the HyperTextAccessible parent first.
4. Adjust the existing character/word/line tests so they ensure that navigation returns the node that has a11y focus; i.e. the text leaf.
Differential Revision: https://phabricator.services.mozilla.com/D57269
--HG--
extra : moz-landing-system : lando
about:support could have an information that WR compositor is disabled by disabling picture caching.
Differential Revision: https://phabricator.services.mozilla.com/D57266
--HG--
extra : moz-landing-system : lando
This switches the OS compositor integration for WR on Windows
off by default.
There are a couple of issues (primarily performance related) that
we need to fix up before making it the default for a release.
Differential Revision: https://phabricator.services.mozilla.com/D57267
--HG--
extra : moz-landing-system : lando
These reftests can be safely removed because all css-namespace tests are
pass in both received/reftest.list and wpt reftests (no
testing/web-platform/meta/css/css-namespaces folder).
The only manual modification in this patch are removing
`os.path.join("css-namespaces"),` in import-tests.py.
Others parts are generated by running import-tests.py on a wpt
repository with commit 15f199c91a72b0d51bf0a12b3b77827ecb5051ff.
Depends on D56376
Differential Revision: https://phabricator.services.mozilla.com/D56377
--HG--
extra : moz-landing-system : lando
When executing `./import-tests.py` in a python virtualenv, the path of
the python interpreter won't be at /usr/bin/python. By using
`/usr/bin/env python`, it works as the system can find a python
interpreter in $PATH.
Differential Revision: https://phabricator.services.mozilla.com/D56376
--HG--
extra : moz-landing-system : lando