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
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
These properties used to be passed to newly created content windows in many
different ways, but are now unified under nsOpenWindowInfo. This patch cleans up
the remaining properties.
Differential Revision: https://phabricator.services.mozilla.com/D67056
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
These properties used to be passed to newly created content windows in many
different ways, but are now unified under nsOpenWindowInfo. This patch cleans up
the remaining properties.
Differential Revision: https://phabricator.services.mozilla.com/D67056
--HG--
extra : moz-landing-system : lando
We won't need these suspend states anymore which were used for media control and audio focus on Fennec.
Differential Revision: https://phabricator.services.mozilla.com/D65265
--HG--
extra : moz-landing-system : lando
The ghost window checker examines windows in all sorts of weird states,
apparently including when the docshell on the outer is null. Add some
fallible variants of the tab group methods on inner and outer windows
so it can call one of those instead.
Differential Revision: https://phabricator.services.mozilla.com/D61203
--HG--
extra : moz-landing-system : lando
This patch does the followings:
1. Remove NotifyOnContentBlocking in WindowOuter and all the call sites.
This is because all the content blocking event handling is moved to the parent.
2. Replace UrlClassifierCommon::NotifyChannelBlocked with AntiTrackingCommon:::NotifyContentBlockingEventInParent.
This is because we don't need to pass the request to the child anymore, which was implemented in NotifyChannelBlocked previously.
3. Add NotifyContentBlockingEvent* utility functions to AntiTrackingCommon.cpp.
4. Update AntiTrackingCommon::NotifyBlockingDecision, when it is called in the parent,
do not send requests to the child, notify the parent directly
Depends on D56874
Differential Revision: https://phabricator.services.mozilla.com/D56875
--HG--
extra : moz-landing-system : lando
This patch does the followings:
1. Remove NotifyOnContentBlocking in WindowOuter and all the call sites.
This is because all the content blocking event handling is moved to the parent.
2. Replace UrlClassifierCommon::NotifyChannelBlocked with AntiTrackingCommon:::NotifyContentBlockingEventInParent.
This is because we don't need to pass the request to the child anymore, which was implemented in NotifyChannelBlocked previously.
3. Add NotifyContentBlockingEvent* utility functions to AntiTrackingCommon.cpp.
4. Update AntiTrackingCommon::NotifyBlockingDecision, when it is called in the parent,
do not send requests to the child, notify the parent directly
Depends on D56874
Differential Revision: https://phabricator.services.mozilla.com/D56875
--HG--
extra : moz-landing-system : lando
Any number of outer windows may be attached to a BrowsingContext over its
lifetime. While the BrowsingContext is alive, it's easy to keep track of which
of these is active, and therefore which of its inner windows is active. After
it has been discarded, though, it discards its docShell reference, so all we
can tell about an inner window is whether it is active for its own outer
window, but not whether it should be considered active for its
BrowsingContext.
This patch updates the BrowsingContext detach logic to store a flag on the
current inner window recording that it was active when its BrowsingContext was
detached, and then later checks that flag to determine if it is the current
window for a detached BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D49032
--HG--
extra : moz-landing-system : lando
The patch moves DeprioritizedLoadRunner handling from top level inner window to top level browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D54754
--HG--
extra : moz-landing-system : lando
Instead of letting the outer window to process `MediaControlActions`, it would be better to handle those actions all in `MediaActionHandler`.
Differential Revision: https://phabricator.services.mozilla.com/D51029
--HG--
extra : moz-landing-system : lando
Any number of outer windows may be attached to a BrowsingContext over its
lifetime. While the BrowsingContext is alive, it's easy to keep track of which
of these is active, and therefore which of its inner windows is active. After
it has been discarded, though, it discards its docShell reference, so all we
can tell about an inner window is whether it is active for its own outer
window, but not whether it should be considered active for its
BrowsingContext.
This patch updates the BrowsingContext detach logic to store a flag on the
current inner window recording that it was active when its BrowsingContext was
detached, and then later checks that flag to determine if it is the current
window for a detached BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D49032
--HG--
extra : moz-landing-system : lando
Bug 1587521 - Enable FullScreen in FxR for Desktop
This change enables Fullscreen functionality in the UI for Firefox Reality for Desktop. On Fullscreen, the window (rather than the desktop) is taken over, and it is up to the host to render the contents as fullscreen.
To mitigate the impact on Desktop's implementation, browser-fullScreenAndPointerLock.js is forked and removes the dependencies on browser.js. These two files will be rationalized at a later time.
Differential Revision: https://phabricator.services.mozilla.com/D48913
--HG--
rename : browser/base/content/browser-fullScreenAndPointerLock.js => browser/fxr/content/fxr-fullScreen.js
extra : moz-landing-system : lando
IsCurrentInnerWindow() should only return true when we are the current inner
of our BrowsingContext, which has a longer lifetime than individual
GlobalWindowOuter instances. In particular, if our BrowsingContext has no
GlobalWindowOuter hanging off it, that means that currently it's hosting an
inner window from some other process and we are not the current inner. If it
_does_ have a GlobalWindowOuter hanging off it, it's possible that this is not
the same as our mOuterWindow, if the BrowsingContext navigated to a different
site and then navigated back to our site.
Therefore, we need to check that we are the current inner of whatever the
BrowsingContext's current GlobalWindowOuter is, if it has one at all.
Differential Revision: https://phabricator.services.mozilla.com/D48595
--HG--
extra : moz-landing-system : lando
Andreas Farre
James Willcox
Eden Chuang
Kris Maglione
Nika Layzell
Narcis Beleuzu
Andrea Marchesini
Csoregi Natalia
Kashav Madan
Noemi Erli
Dimi Lee
Cosmin Sabou
Ehsan Akhgari
Alastor Wu
Matt Woodrow
Jonathan Watt
Andrew McCreight
Brindusan Cristian
pbz
Oana Pop Rus
Olli Pettay
Emilio Cobos Álvarez
thomasmo