If afterprint removes the window we're printing, we'd call
LeaveModalState() without a top window, and never leave the modal state.
Differential Revision: https://phabricator.services.mozilla.com/D115007
Non-SHIP bfcache seems to be rather complicated here, since it needs to explicitly store inner windows and what not.
SHIP should be able to handle this in a simpler way.
It is possible that some ordering needs still tweaking.
Differential Revision: https://phabricator.services.mozilla.com/D105360
Non-SHIP bfcache seems to be rather complicated here, since it needs to explicitly store inner windows and what not.
SHIP should be able to handle this in a simpler way.
It is possible that some ordering needs still tweaking.
Differential Revision: https://phabricator.services.mozilla.com/D105360
Preserve the last state of when we focused the element in that window,
if the focus method is unknown.
Depends on D104861
Differential Revision: https://phabricator.services.mozilla.com/D104863
We only use the contentBlockingAllowListPrincipal for excluding sites from content
blocking for top level documents. We don't need it in the content process and should
not compute it for every document.
Differential Revision: https://phabricator.services.mozilla.com/D100781
Rework the MediaKeys class to shutdown when its parent inner window is destroyed
rather than the document it's created in. This is done to mitigate the case
where a MediaKeys is created in an about:blank document that has not yet
undergone its async load (i.e. blank document that will stay blank, blank
documents loading to other pages will still clobber their keys on load). This
specifically addresses cases where sites could create an iframe, not wait for
load, create a MediaKeys in the iframe, and then find the keys had become
unusable.
This is achieved by associating MediaKeys instances with their inner window and
having the window notify keys when a window is going to be destroyed. I decided
to use this approach rather than have MediaKeys observe for window destruction
for a few reasons:
- The keys would need to support weak references to use the observer service in
the desired way. Implementing this interface on the MediaKeys adds a
non-trivial level of complexity and means the keys would implement the WeakPtr
interface (already in place prior to this patch) and also the NS weak
reference interface, which I found confusing.
- If the inner window stores pointers to MediaKeys created in it, it can be self
aware of if EME activity is taking place within it. The allows us to better
identify EME activity in documents. Historically one of the ways we'd
determined EME activity by checking if media elements have MediaKeys attached,
but this had lead to issues where if MediaKeys are created but not attached
to a media element we overlook them. With this patch's changes, we can also
have a document check its inner window to see if there are any MediaKeys. This
patch uses this to extend our check to avoid bfcaching pages with EME content.
- There appears to be prior art using a similar approach for audio contexts and
peer connections, which I assume is sensible and I'm not reinventing the wheel
by following.
Differential Revision: https://phabricator.services.mozilla.com/D98641
A new `BrowsingContext` field 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
A new `BrowsingContext` field 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
On Nightly, for now. This allows websites to get the real viewport size.
The rounded size has caused problems in the past (see bug 1648298 / bug
1648265), and changing it would be ideal.
I told the CSSWG that we can experiment with this on Nightly to
alleviate (or prove) compat concerns, in which case we'd need to use a
different solution, see https://github.com/w3c/csswg-drafts/issues/5260.
Differential Revision: https://phabricator.services.mozilla.com/D96826
There is similar API in `Document`, but they indicate whether a node has been
observed by any mutation receiver, not only by `MutationObserver` of JS.
However, I'd like to know the percentage of web apps which use
`MutationObserver`, but not use `beforeinput` events. Therefore, this patch
adds similar API into `nsPIDOMWindowInner` as same as `beforeinput` and
ignores `MutationObserver`s which are created by chrome script and addons.
Differential Revision: https://phabricator.services.mozilla.com/D92547
When `HTMLEditor` instances are destroyed, I'd like to collect how much
instances are worked with `beforeinput` event listeners. Before adding such
telemetry probe, this patch adds methods to set/get whether a `beforeinput`
event listener has had added or not to `nsPIDOMWindowInner`.
Differential Revision: https://phabricator.services.mozilla.com/D92546
The telemetry probe was added in bug 1506434, and it's not necessary anymore
because of the event in the default group was completely disabled in
bug 1288640 (Gecko 65).
Therefore, we can get rid of the pref, and we can take back a room for a
bool member in `nsPIDOMWindowInner` for new telemetry probes which need
to know whether a specific event listener has been added or not.
Depends on D92395
Differential Revision: https://phabricator.services.mozilla.com/D92397
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 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
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
Adds an |aChromeOnlyDispatch| flag to DispatchCustomEvent to decide whether
to call DispatchTrustEvent or DispatchEventOnlyToChrome.
The following chrome-only events are dispatched with DispatchCustomEvent and now
make use of the flag:
- DOMWindowClose
- fullscreen / willenterfullscreen / willexitfullscreen
- occlusionstatechange
- resolutionchange
- XULAlertClose
and the following were previously dispatched with DispatchTrustedEvent and now
use DispatchEventOnlyToChrome:
- MozBeforeInitialXULLayout
- MozMouseScrollFailed / MozMouseScrollTransactionTimeout
- MozPaintWait / MozPaintWaitFinished
- MozPerformDelayedBlur
- all events fired by APZCCallbackHelper::NotifyMozMouseScrollEvent
Differential Revision: https://phabricator.services.mozilla.com/D76723
Before this patch, in non-fission mode, we cache storage access granted result
in the top-level window so we don't have to iterate all the browsing contexts
in the same tree while syncing the storage permission granted decision.
However, since we plan to rely on the current update mechanism to sync
mHasStorageAccess flag for different documents in the same tab (instead of using
the syncing mechanism of permission manager), we will eventually need to iterate
the browsing context tree to find all the documents to sync. Base on this,
we no longer have to maintain different method for fission and non-fission.
In this patch, we store the permission granted result in the inner
window instead of using permission key and store the key in the top-level
window.
Differential Revision: https://phabricator.services.mozilla.com/D73710
