Any time we QI to nsIFrameLoaderOwner in tests, we're really accessing
a MozFrameLoader. We don't need to be doing that anymore.
Differential Revision: https://phabricator.services.mozilla.com/D19727
--HG--
extra : moz-landing-system : lando
* New topLevel loads get the nsILoadInfo.openerPolicy of the current top level document
* Parsing the Cross-Opener-Origin-Policy of a channel will update mLoadInfo.openerPolicy and this value will get propagated to the child process.
* SessionStore now checks nsIHttpChannel.hasCrossOriginOpenerPolicyMismatch (preffed off) and performs a process switch if needed
Differential Revision: https://phabricator.services.mozilla.com/D19000
--HG--
rename : toolkit/components/remotebrowserutils/tests/browser/browser_httpResponseProcessSelection.js => toolkit/components/remotebrowserutils/tests/browser/browser_httpCrossOriginOpenerPolicy.js
extra : moz-landing-system : lando
- Adds nsIHttpChannelInternal.setTopWindowPrincipal used to pass the principal from the child to the parent
Differential Revision: https://phabricator.services.mozilla.com/D18391
--HG--
extra : moz-landing-system : lando
Some functionality is intentionally unimplemented to make this patch
smaller and at a faster cadence: field initializers are stored on
this['.initializers'] instead of a local, derived classes are not
supported yet, and constant-folding/inline field initializers are not
implemented.
Differential Revision: https://phabricator.services.mozilla.com/D16343
--HG--
extra : moz-landing-system : lando
Because the mock no longer checks whether the format of events is
correct, check the events that Telemetry actually records, in order to
make sure we conform to the event schema.
Some uses check that *no* calls were made to the stub. Although this
is technically still valid (because we don't care about the format of
events in this case), convert even these to check events for
consistency.
TelemetryTestUtils.assertEvents doesn't allow us to pass a message,
but most of these messages don't add anything useful and at least one
is just wrong so it's not a big loss.
Depends on D19540
Differential Revision: https://phabricator.services.mozilla.com/D19831
--HG--
extra : moz-landing-system : lando
This also means we no longer have direct access to the event schema,
so rely on Telemetry to throw when we send an invalid event.
Differential Revision: https://phabricator.services.mozilla.com/D19540
--HG--
extra : moz-landing-system : lando
If the AudioContext is suspended by content or by Autoplay policy, it shouldn't be resumed by chrome.
Differential Revision: https://phabricator.services.mozilla.com/D19451
--HG--
extra : moz-landing-system : lando
Different nodes might have same AudioParam, so we shouldn't append same stream multiple times.
Differential Revision: https://phabricator.services.mozilla.com/D19450
--HG--
extra : moz-landing-system : lando
The element has never existed in the new process, so it gets a missing
error rather than a stale error in that case.
Depends on D19692
Differential Revision: https://phabricator.services.mozilla.com/D19829
--HG--
extra : moz-landing-system : lando
For HTTP loads from the preloaded document, no process swap was occuring
if the preloaded document was loaded in a 'web' process. This caused
test failures, and has potentially undesireable behaviour.
This patch just moves the check for preloaded document swaps to before
the check for http parent process interception, forcing a swap like
normal.
Depends on D19691
Differential Revision: https://phabricator.services.mozilla.com/D19692
--HG--
extra : moz-landing-system : lando
Issues were occuring where a process swap would be decided upon during
on-examine-response, but before the swap could be handled by the
channel, the channel was redirected.
This new code takes the mildly hacky approach of simply using a separate
observer notification which is fired at the correct time. A better
solution may be to use a dedicated service for responding to these
events, however that was not implemented for this initial patch.
Depends on D18606
Differential Revision: https://phabricator.services.mozilla.com/D19691
--HG--
extra : moz-landing-system : lando
Just for my sanity. I think the other scroll observer is sane after a quick
look, but this will ensure we don't ship security issues.
Differential Revision: https://phabricator.services.mozilla.com/D19725
--HG--
extra : moz-landing-system : lando
The primary frame hashtable is long gone; we have a pointer on the node now.
Differential Revision: https://phabricator.services.mozilla.com/D19952
--HG--
extra : moz-landing-system : lando
The kvstore crate that landed in bug 1490496 uses an internal implementation of OwnedValue because the rkv crate's equivalent was insufficient at the time that kvstore was being developed.
rkv's OwnedValue has since evolved to support kvstore's use cases, and bug 1525392 is updating mozilla-central to the latest version of rkv; so we should replace kvstore's internal OwnedValue with rkv::OwnedValue.
Differential Revision: https://phabricator.services.mozilla.com/D19436
--HG--
extra : moz-landing-system : lando