I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
This pref was enabled on all platforms, and the codepath which has it disabled
has been untested for some time. Remove the pref to simplify the code handling
the old case.
Differential Revision: https://phabricator.services.mozilla.com/D78974
As tabbrowser now uses `PROCESS_BEHAVIOR_STANDARD`, `PROCESS_BEHAVIOR_CUSTOM` is
now unused. This patch removes that now-unused code.
Differential Revision: https://phabricator.services.mozilla.com/D78972
Add a series of extra hooks and methods to allow tabbrowser to use the new
process switching codepath. This duplicates some of the logic from
`updateBrowserRemoteness` into event handlers.
Differential Revision: https://phabricator.services.mozilla.com/D78970
This new process switching behavior is only enabled for some browser elements,
which have specified a specific attribute. Turning this on for all browsers with
a `remote` attribute causes breakage in reftests.
The initial version does not handle switching from remote to parent or
vice-versa, that is covered in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D78969
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
This pref was enabled on all platforms, and the codepath which has it disabled
has been untested for some time. Remove the pref to simplify the code handling
the old case.
Differential Revision: https://phabricator.services.mozilla.com/D78974
As tabbrowser now uses `PROCESS_BEHAVIOR_STANDARD`, `PROCESS_BEHAVIOR_CUSTOM` is
now unused. This patch removes that now-unused code.
Differential Revision: https://phabricator.services.mozilla.com/D78972
Add a series of extra hooks and methods to allow tabbrowser to use the new
process switching codepath. This duplicates some of the logic from
`updateBrowserRemoteness` into event handlers.
Differential Revision: https://phabricator.services.mozilla.com/D78970
This new process switching behavior is only enabled for some browser elements,
which have specified a specific attribute. Turning this on for all browsers with
a `remote` attribute causes breakage in reftests.
The initial version does not handle switching from remote to parent or
vice-versa, that is covered in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D78969
We can get two calls to enterResponsiveMode() for a tab, via the two
callsites in devtools/client/responsive/ui.js.
Calling enterResponsiveMode() is not idempotent after bug 1634621, as
the second call will lose the zoom information. Prevent this from
happening by making the call a no-op if we're already in responsive
mode.
Do the same in leaveResponsiveMode() for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D78294
This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
Differential Revision: https://phabricator.services.mozilla.com/D75447
This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
Differential Revision: https://phabricator.services.mozilla.com/D75447
Fix up the browser_tab_label_during_restore.js test to wait for the right number of tab title changes, since the timing of the tab title updating has now changed.
Differential Revision: https://phabricator.services.mozilla.com/D72562
Fix up the browser_tab_label_during_restore.js test to wait for the right number of tab title changes, since the timing of the tab title updating has now changed.
Differential Revision: https://phabricator.services.mozilla.com/D72562
Fix up the browser_tab_label_during_restore.js test to wait for the right number of tab title changes, since the timing of the tab title updating has now changed.
Differential Revision: https://phabricator.services.mozilla.com/D72562
This value is determined in Parent process and passed down to nsDocShell. Delete
the messages to pass the setting down and set it on the BrowsingContext in the
Parent process.
Refactor the code that determines to opt-out of using global history. Code
inspection determines that windowless browsing contexts want to opt-out as well
as any frame with `disableglobalhistory` attribute set on it.
Differential Revision: https://phabricator.services.mozilla.com/D72279
LazyFC changes the way we initialize browsers in a subtle way which is
important for print preview and PiP.
When creating a print preview browser / PiP, we rely on getting the right
process via _sameProcessAsFrameLoader. This is set very early on the
lifetime of the browser element, after it's upgraded but before its
connectedCallback() calls.
What happens with LazyFC is that we append the browser to the document,
then set its sameProcessAsFrameLoader, then initialize the browser from
connectedCallback(). That calls resetFields() _after_ setting the
_sameProcessAsFrameLoader, which clears it out, not good.
Without LazyFC we initialize it via frame construction, as soon as the
browser is attached to the document, so all ends up working out.
Explicitly avoid clearing this field out if not initialized yet, instead
of the hasOwnProperty check which was for the very same thing, just
about XBL initialization.
Differential Revision: https://phabricator.services.mozilla.com/D74282
That avoids having two sources of truth. This might be better, still
unsure how I feel about it compared to the current setup.
Differential Revision: https://phabricator.services.mozilla.com/D73427
Bug 1633938 re-introduced this field to handle full-zoom on RDM without
having to affect the actual content zoom, see related hacks that went
away in this push:
9e6925ea79
But I added it to the browser element constructor, instead of to
resetFields(), which means that it's not properly reset when the
browsing context changes and thus it can get out of sync.
Move it to resetFields(), so that we properly detect that zoom has
changed. An alternative to this is to only use this._fullZoom when in
RDM instead.
This is where a similar field only used for remote browser used to live
before my Fission zoom changes:
https://searchfox.org/mozilla-central/rev/9642a113737b556750228965bb9cbd3aaa655e22/toolkit/content/widgets/browser-custom-element.js#346
Differential Revision: https://phabricator.services.mozilla.com/D73426
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
Implemecurnt a flag `suspendMediaWhenInactive` on the docShell that indicates media in that shell should be suspended when the shell is inactive. Currently, only GeckoView is using this flag.
---
The reason of implementing this flag is because in bug1577890 we remove the old way to suspend/resume the media, and I thought setting docshell to inactive is enough to suspend the media because we already have a mechanism which would suspend/resume media when document becomes inactive/active [1].
However, the active state of document is actually different from what I thought it was. Setting docshell to inactive won't change the document's active state, because that indicates if the document is the current active document for the docshell [2] (docshell can have multiple documents), instead of indicating if the docshell is active or not.
Therefore, we have to add another flag to indicate if the docshell wants to suspend its media when it's inactive, in order to use current mechanism to suspend/resume media.
[1] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/html/HTMLMediaElement.cpp#6453
[2] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/base/Document.h#2627-2633
Differential Revision: https://phabricator.services.mozilla.com/D69669
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
