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
Add importableLogins autocomplete items that show for a site when there's chromium-based logins, no saved logins, and appropriate experiment state. Default behavior is unchanged with default "" pref value, and new behavior can be turned on with "import" pref value.
Differential Revision: https://phabricator.services.mozilla.com/D72096
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
Instead of forcing a sync layout flush every time the autocomplete popup is opened, this forces a less expensive sync style flush instead (see [diff profile](https://perfht.ml/2VKZF77)). This results in a 29% performance improvement in the time it takes to show the autocomplete popup on my machine (Bug 1619498; average time across 5 measurements for the _first time_ the popup is shown went from 45 ms down to 32 ms).
Other approaches that were considered to avoid any flushing:
* `windowUtils.getBoundsWithoutFlushing`: Unfortunately, `getBoundingClientRect` couldn't be replaced with `windowUtils.getBoundsWithoutFlushing`, because the previously computed width of the popup is `0` when it is first shown, due to it starting out hidden (i.e. `display: none`).
* `promiseDocumentFlushed`: This method is async while all of the surrounding autocomplete UI code is sync, so while it's not impossible, it would be difficult to implement a simple fix.
Differential Revision: https://phabricator.services.mozilla.com/D71254
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