I have to debug this test and some of these are failing. It'd be good to know
which one of these fail separately.
Differential Revision: https://phabricator.services.mozilla.com/D46558
--HG--
extra : moz-landing-system : lando
This fixes both our failure to register load blockers for remote frames and
our failure to keep the load event blocked during frameloader rebuilding on
remoteness change.
Differential Revision: https://phabricator.services.mozilla.com/D46503
--HG--
extra : source : dff7756afe8ede1e03d775ec4999d4807d82c1da
extra : histedit_source : b02eae2b652683ef17be3e0ff6a908b4bec311f5%2Cc62c8e5e4ca066f8f526a81a9aae0feeb84326a5
BrowsingContext.findWithName is required to do access checks based on the
requestor, which can only be done in the process which owns it. This change
also alters the behavior of the existing CanAccess origin checks, which
typically treat any item as same-origin, but only when the docshells are
actually same process.
Removing the exemption fixes the behavior discrepancy between Fission and
non-Fission runs, but also requires that the test be updated to expect proper
access checks. Which is the situation we really want to test, anyway.
Differential Revision: https://phabricator.services.mozilla.com/D45837
--HG--
extra : moz-landing-system : lando
`IMEContentObserver` sends selection change notification only when it receives
a DOM `Selection` change notification received. However, selection range in
plaintext offset may be changed when changing previous content of caret is
changed. In this case, currently we notify IME of only text change and
that causes IME keep caching selection offsets in previous content. This
causes IME queries character rect out of bounds. Therefore, even if
`IMEContentObserver` hasn't received DOM `Selection` change notification,
it should recompute selection range and if it's changed, it should notify
IME of selection change too.
Differential Revision: https://phabricator.services.mozilla.com/D46251
--HG--
extra : moz-landing-system : lando
This fixes both our failure to register load blockers for remote frames and
our failure to keep the load event blocked during frameloader rebuilding on
remoteness change.
Differential Revision: https://phabricator.services.mozilla.com/D46503
--HG--
extra : moz-landing-system : lando
Using the BrowsingUsing parent chain is able to avoid 1) obtaining a wrong
root in cross-process documents and also avoid 2) not being able to obtain
the proper root in same-origin documents in the case where there is a
cross-process document in between the top level document and the same-origin
documents.
dom/base/test/test_intersectionobservers.html is a test of case 1).
testing/web-platform/tests/intersection-observer/same-origin-grand-child-iframe.sub.html
is a test case of case 2).
Differential Revision: https://phabricator.services.mozilla.com/D46432
--HG--
extra : moz-landing-system : lando
When running in debug builds, the test will use the default timings instead of the faster ones.
Differential Revision: https://phabricator.services.mozilla.com/D46476
--HG--
extra : moz-landing-system : lando
There is still another related bug 1579591, which this may make a bit less likely, since that seems to be timing dependent, but
the patch is not trying to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D46242
--HG--
extra : moz-landing-system : lando
In some situations, entries may in fact take more than half the buffer size
(e.g., when duplicating a stack into a small temporary buffer).
So we now allow blocks to take the full buffer size -- but not more, as they
would start overwriting themselves!
Differential Revision: https://phabricator.services.mozilla.com/D46453
--HG--
extra : moz-landing-system : lando
* wpt runs chrome priv for a subset of tests (mostly things testing toolkit chrome stuff), but it's still in the content process
* we only ever hit this case if the test is explicitly loaded as chrome. originally added for a couple osx tests at https://bugzilla.mozilla.org/show_bug.cgi?id=1465457. then expanded for all xul tests at https://bugzilla.mozilla.org/show_bug.cgi?id=1557371
* so what we used to do here is run xul/xbl in the content process (not chrome priv)
* the change here is that with our chrome Custom Elements we need to run with chrome priv for https://searchfox.org/mozilla-central/rev/4218cb868d8deed13e902718ba2595d85e12b86b/toolkit/components/processsingleton/CustomElementsListener.jsm#16 to load the elements
* so we made it explicit. the alternative at the time was to change wpt harness to load these tests in parent process, but it was too complex for what we needed (discussed with dbaron)
* this parentprocess check was meant kind of as an optimization so that we wouldn't have to check priv on random pages. but (a) that's short circuited anyway by the xul elem check and (b) this is only called when attachShadow is called on a non-html element so not in any kind of hot path
Differential Revision: https://phabricator.services.mozilla.com/D46310
--HG--
extra : moz-landing-system : lando
