Popup permissions initialized with the result of checking if the
constructing WindowContext's principal is allowed to open a popup. The
field is updated for all WindowContexts sharing a principal whenever
the popup permission for that nsIPrincipal changes.
Differential Revision: https://phabricator.services.mozilla.com/D86378
A new `BrowsingContext` field, `isActiveBrowserWindow`, has been added
to track the active browser window for the `:-moz-window-inactive`
pseudoclass. This field takes the place of
`nsPIDOMWindowOuter::mIsActive`.
With this change `:-moz-window-inactive` is now fission compatible.
Differential Revision: https://phabricator.services.mozilla.com/D86422
This should help catch and/or prevent any cases where we're creating a new
subframe at an unfortunate time during `BrowsingContext` or `WindowContext`
teardown.
Differential Revision: https://phabricator.services.mozilla.com/D85896
This patch enables sandboxed srcdoc loads to take place via DocumentChannel,
and adds mechanisms for enabling unsandboxed ones.
Both unsandboxed srcdoc, and in subsequent patches, about:blank, loads require
that the triggering principal and the principal to inherit point to the same
instance if the load takes place in the same process as where we are inheriting
those principals from. We save those principals on a target browsing context before
we load the URI, and later, when we are deserializing LoadInfoArgs into
LoadInfo in the content process, we retrieve the saved principals if the
current load identifier of the target BC matches the load identifier saved
along with the principals.
We also need to make sure that during a process switch for about:srcdoc load,
we don't use the original URI for about:srcdoc to determine the remote type and
instead we use channel's result principal.
Differential Revision: https://phabricator.services.mozilla.com/D85079
This should ensure that any BrowsingContexts racily created during the discard
process don't end up creating a separate BrowsingContextGroup from their
relatives, and triggering group mismatch assertions.
Differential Revision: https://phabricator.services.mozilla.com/D84548
This requires keeping track of the current process used to host documents with a
particular remote type loaded in each BrowsingContextGroup. Due to lifecycle
oddities, this set is kept separate from the existing subscribers set on
BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D84061
This should ensure that any BrowsingContexts racily created during the discard
process don't end up creating a separate BrowsingContextGroup from their
relatives, and triggering group mismatch assertions.
Differential Revision: https://phabricator.services.mozilla.com/D84548
This requires keeping track of the current process used to host documents with a
particular remote type loaded in each BrowsingContextGroup. Due to lifecycle
oddities, this set is kept separate from the existing subscribers set on
BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D84061
This avoids problems where a foreground tab tries to communicate with a background
tab via `window.opener`, but is unable to because the background tab
is suspended.
Differential Revision: https://phabricator.services.mozilla.com/D83693
CLOSED TREE
Backed out changeset 51d7c644a1e6 (bug 1650163)
Backed out changeset 3d2b6908447a (bug 1650163)
Backed out changeset 79141707d47b (bug 1650163)
This is only used by Thunderbird, and is always true for Firefox. I've made CanSet only allow the embedder process, which is the desired behaviour, and should work for non-e10s.
Differential Revision: https://phabricator.services.mozilla.com/D80109
This is only used by Thunderbird, and is always true for Firefox. I've made CanSet only allow the embedder process, which is the desired behaviour, and should work for non-e10s.
Differential Revision: https://phabricator.services.mozilla.com/D80109
This patch also makes the identifier for channels global, in the sense
that the generated identifier is generated outside of and passed to
the nsIRedirectChannelRegistrar.
Differential Revision: https://phabricator.services.mozilla.com/D79820
We can just use BrowsingContext::BrowserId directly, so it's unnecessary to have
the field on nsFrameLoaderOwner as well.
This also makes it so that we only ever generate browser IDs in
BrowsingContext::CreatedDetached.
Differential Revision: https://phabricator.services.mozilla.com/D80121
