Instead of collecting data from the entire tree of documents, we
collect data per document. The collected data is sent to the
corresponding parent window context and is applied incrementally to
the tab state cache.
Differential Revision: https://phabricator.services.mozilla.com/D107814
We need a call to nsFrameLoader::RequestTabStateFlush to flush the
toplevel context first. That way we can ensure that session storage is
flushed consistently.
Differential Revision: https://phabricator.services.mozilla.com/D108938
Instead of collecting data from the entire tree of documents, we
collect data per document. The collected data is sent to the
corresponding parent window context and is applied incrementally to
the tab state cache.
Differential Revision: https://phabricator.services.mozilla.com/D107814
This is in practice the behavior already, because swap is really a move and removing the old tab, and
when removing the other tab, the bfcached frameloaders are destroyed. But they stay still in the session history.
So this patch clears session history explicitly.
As long as we have message managers, we can't really support bfcache in this case, since we can't swap message managers,
there are no corresponding managers on the other side.
Message managers need to stay always in the original window, since the listeners are from there.
WindowActors do move with frameloader/browsingcontext, but that leads easily to memory leaks.
https://bugzilla.mozilla.org/show_bug.cgi?id=1697918 is about that and it has nothing to do with bfcache.
Differential Revision: https://phabricator.services.mozilla.com/D108273
Previously, we would need to suspend progress events from the previous
BrowserParent, as otherwise we would receive STATE_STOP progress notifications
from the previous browser when it is destroyed, which would throw off frontend
code. With the new checks added by part 1, we will now catch these cases by
detecting that the current window global has changed, and we can get rid of this
explicit override.
Differential Revision: https://phabricator.services.mozilla.com/D105557
The name RemotenessChangeState uses same the convention as the related methods, even though there might
not be a remoteness change happening, only a browsing context switch. But the naming
inconsistency exists there even without any bfcache work.
RemotenessChangeState will be renamed to RemotenessChangeOptions in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D105229
The name RemotenessChangeState uses same the convention as the related methods, even though there might
not be a remoteness change happening, only a browsing context switch. But the naming
inconsistency exists there even without any bfcache work.
RemotenessChangeState will be renamed to RemotenessChangeOptions in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D105229
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
Thunderbird loads moz-extension: pages in about:preferences to allow configuration of FileLink extensions. When remote extensions are enabled this will need to be done with a remote browser.
Differential Revision: https://phabricator.services.mozilla.com/D99844
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
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
Otherwise we end up creating an in-process docshell and an initial,
non-static subdocument. This usually won't cause badness, but is wrong
and _can_ cause badness when printing selection etc.
The assertion I added is hit on existing tests and would've caught this.
Also fix another violation by grabbing the original docshell to clone
from before actually performing the clone, which could be null (and we'd
leave an initial document there). That would cause failures in
layout/printing/crashtests/1662259.html.
Differential Revision: https://phabricator.services.mozilla.com/D93279
