Bug 1598523 added an assertion that if INTERNAL_LOAD_FLAGS_IS_SRCDOC is not set
in a load state's load flags, then the srcdoc must be a void string.
nsDocShell::Reload never set srcdoc to a void string in that case, and wasn't
fixed up.
Differential Revision: https://phabricator.services.mozilla.com/D75908
This patch will do :
- create a sync field `AutoplayPermission` on WindowContext
- update the field whenever site's the autoplay permission changes
The advantage of doing so :
- to help determine the result of the blocking autoplay correctly.
More details :
As the field would be automatically synced between processes, then we can know the correct site's autoplay permission for the whole page even if we're in the different process if the iframe is in different origin after we enable Fission.
Differential Revision: https://phabricator.services.mozilla.com/D74511
This enables navigating by index in session history go through the
session history in the parent (if enabled with the pref).
If the pref is enabled, then ChildSHistory::Go will send an IPC message
to the parent with the index to navigate to. The parent calls the
existing nsSHistory implementation and starts the loads, and
asynchronously returns the index that we actually navigated to. The
child process then uses that result to update the session history
implementation in the child process (this part is temporary, while we
have session history both in parent and in child). We also make the
parent send an updated length to the child process over IPC, so that
history.length always the length for the implementation in the parent.
Differential Revision: https://phabricator.services.mozilla.com/D65330
This adds a new implementation of nsISHEntry
(mozilla::dom::SessionHistoryEntry). When session history in the parent
is turned on, we'll instantiate the existing nsSHistory in the parent
process, but it will store entries of this new type. The nsSHistory in
the child process will also be instantiated for now, to avoid breaking
too many assumptions, and we try to keep parent and child
implementations in sync.
mozilla::dom::SessionHistoryEntry stores most of its data in a new
structure (mozilla::dom::SessionHistoryInfo) which can be sent over IPC.
When a load starts through the DocumentChannel we create an entry of
this new type for it in the parent process in
DocumentLoadListener::Open. The SessionHistoryInfo for that entry (with
an associated ID) is then sent over IPC in the RedirectToRealChannelArgs
to the process that does the actual load, where we store it in the
nsDocShell in mLoadingEntry (and mLoadingEntryId). The parent process
keeps track of outstanding loading entries in an array (mLoadingEntries)
in the CanonicalBrowsingContext. When a load finishes the nsDocShell
transfers mLoadingEntry into mActiveEntry, and notifies the parent
process through an IPC message (HistoryCommit) with the id of that
entry. The CanonicalBrowsingContext then removes the entry from the
array and stores it in its mActiveEntry, and adds the entry to the
nsSHistory object.
There are a number of things in this patch that are broken, and a lot of
FIXME comments. However, with the pref turned off things should just be
working as before. The goal is to land this first part, and then iterate
on the new implementation until we can switch over.
Differential Revision: https://phabricator.services.mozilla.com/D65329
This patch persists the CrossOriginEmbedderPolicy on the Document and
WindowContext.
The WindowContext's embedder policy is set in
WindowGlobalActor::BaseInitializer by either adopting the policy of the HTTP
channel that loaded the document, or in WindowGlobalChild::OnNewDocument
by inheriting the one from the browsingContext's windowContext.
Differential Revision: https://phabricator.services.mozilla.com/D46903
This should make the flow of how data gets into the initial WindowContext state
more clear, and allows the setting of initial synced WindowContext fields.
Differential Revision: https://phabricator.services.mozilla.com/D74324
The entire CookieJarSettingsArgs is currently being synced into every content
process, when only two fields of that structure are actually needed.
Those two fields are extracted from the CookieJarSettingsArgs and synchronized
separately to avoid leaking information such as principals into every content
process.
Differential Revision: https://phabricator.services.mozilla.com/D74258
The entire CookieJarSettingsArgs is currently being synced into every content
process, when only two fields of that structure are actually needed.
Those two fields are extracted from the CookieJarSettingsArgs and synchronized
separately to avoid leaking information such as principals into every content
process.
Differential Revision: https://phabricator.services.mozilla.com/D74258
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
The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
This patch asserts in various places that our LoadContext value on
BrowsingContext is consistent. This is done in order to get better diagnostics
for crashes such as those in bug 1629527.
Differential Revision: https://phabricator.services.mozilla.com/D72931
The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
This patch asserts in various places that our LoadContext value on
BrowsingContext is consistent. This is done in order to get better diagnostics
for crashes such as those in bug 1629527.
Differential Revision: https://phabricator.services.mozilla.com/D72931
This patch will do :
- rename `PlaybackController` to `ContentPlaybackController`
The advantage of doing so :
- explicitly mention this class is only used in the content, to help its readbility
Differential Revision: https://phabricator.services.mozilla.com/D72939
This patch will do :
- rename `MediaActionHandler` to `ContentMediaActionHandler`
The advantage of doing so :
- explicitly mention this class is only used in the content, to help its readbility
Differential Revision: https://phabricator.services.mozilla.com/D72938
This removes processing of HTTP Public Key Pinning headers, remotely modifying
pinning information, and using cached pinning information, all of which was
already disabled in bug 1412438. Static pins that ship with the browser are
still enforced.
Differential Revision: https://phabricator.services.mozilla.com/D73352
This is a very first iteration of about:processes, so that people who actually need the tool can start using it immediately and provide feedback.
Differential Revision: https://phabricator.services.mozilla.com/D72617
The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
This patch asserts in various places that our LoadContext value on
BrowsingContext is consistent. This is done in order to get better diagnostics
for crashes such as those in bug 1629527.
Differential Revision: https://phabricator.services.mozilla.com/D72931
This is a very first iteration of about:processes, so that people who actually need the tool can start using it immediately and provide feedback.
Differential Revision: https://phabricator.services.mozilla.com/D72617
This is a very first iteration of about:processes, so that people who actually need the tool can start using it immediately and provide feedback.
Differential Revision: https://phabricator.services.mozilla.com/D72617
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
This is a very first iteration of about:processes, so that people who actually need the tool can start using it immediately and provide feedback.
Differential Revision: https://phabricator.services.mozilla.com/D72617
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
There are various times when it would be useful to get the toplevel or parent
WindowContext from a window or browsing context. While this is already possible,
it's currently somewhat inconvenient.
Differential Revision: https://phabricator.services.mozilla.com/D73500
After the recent simplifications to the zoom code, they only take care
of forwarding the enlarge / decrease zoom messages.
We can do that via PBrowser instead, and get rid of the actors. We can
also remove ZoomChangeUsingMouseWheel. Zooming with the mouse wheel will
end up in a *ZoomChange event anyways, and the only consumer already
listened for them.
Differential Revision: https://phabricator.services.mozilla.com/D73175
This ensures that chrome code can always react to the state the browsing
context the parent process observes properly. It's also simpler.
We fix one test that was relying on the event being fired at the
browser. For the same reason as the previous patch in this bug, we can
use resize events instead.
Differential Revision: https://phabricator.services.mozilla.com/D72712
Things that were broken:
- prompts become unreadable when using dark-background lwthemes, because they
keep the window text-shadow (due to the namespace change of tabmodalprompt)
- prompts with long text without word-wrap possibilities
(e.g. `alert("x".repeat(1000))`) cause the text to escape its container.
Differential Revision: https://phabricator.services.mozilla.com/D73131
This ensures that chrome code can always react to the state the browsing
context the parent process observes properly. It's also simpler.
We fix one test that was relying on the event being fired at the
browser. For the same reason as the previous patch in this bug, we can
use resize events instead.
Differential Revision: https://phabricator.services.mozilla.com/D72712
We don't access HasStoragePermission across process, so we don't need to
store the permission in WindowContext.
After this patch, HasStoragePermission will only be stored in the
channel's LoadInfo, which is set when a channel is created in the parent
and it won't be updated.
Depends on D71985
Differential Revision: https://phabricator.services.mozilla.com/D72305
Both the deprecated `Screen.lockOrientation` and replacement
`ScreenOrientation.lock` APIs have been updated to make use of a new
`OrientationLock` field on the `BrowsingContext`. This replaces the
storage and use of APIs for this on the root docshell.
In the non fission case things should behave the same, as pending
promises for previous calls to `Screen.lockOrientation` will still be
cancelled in process. If there are `BrowsingContext`s in other
processes though, IPC will be sent to the parent, and then each other
child to cancel them. This should be spec compliant as the spec is
already racy with regards to multiple `lockOrientation` calls.
This new implementation has a little extra IPC than the optimal
implementation would since the root `BrowsingContext`s
`OrientationLock` is set using the normal `SyncedContext` machinery,
rather than combining the `AbortOtherOrientationPendingPromises`
message for a single message.
This commit fixes both Bug 1597413 and Bug 1597443.
Differential Revision: https://phabricator.services.mozilla.com/D70416
In BrowsingContext::SetDocShell(), we indicate that any remote outer window
proxies need to be cleaned up, if we've transitioned from a remote window
proxy to a local one. However, we don't actually do the cleanup until
nsGlobalWindowOuter::SetNewDocument(), so don't assert if we find remote
window proxies when we're in between these two periods.
Also includes a formatting fix by clang-format.
Differential Revision: https://phabricator.services.mozilla.com/D72251
Due to the refactored code,
browser/base/content/test/performance/browser_preferences_usage.js started
reporting more accesses to browser.cache.check_doc_frequency preference.
Differential Revision: https://phabricator.services.mozilla.com/D68319
This was previously true, since we only used ResumeRedirectedLoad with a brand new docshell. This bug adds code for using it with existing docshells, which can have any Document (and associated timing object) loaded in them.
Differential Revision: https://phabricator.services.mozilla.com/D67097
Same process origin changes are handled by the docshell, which detects this during AsyncOnChannelRedirect and clears the mixed content permission.
Process switches load in a fresh docshell, so we need to make sure we appropriately set or clear the mixed content permission.
Differential Revision: https://phabricator.services.mozilla.com/D67095
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
This was previously true, since we only used ResumeRedirectedLoad with a brand new docshell. This bug adds code for using it with existing docshells, which can have any Document (and associated timing object) loaded in them.
Differential Revision: https://phabricator.services.mozilla.com/D67097
Same process origin changes are handled by the docshell, which detects this during AsyncOnChannelRedirect and clears the mixed content permission.
Process switches load in a fresh docshell, so we need to make sure we appropriately set or clear the mixed content permission.
Differential Revision: https://phabricator.services.mozilla.com/D67095
Add ParentProcessDocumentChannel object. This object is a DocumentChannel that will start a channel load from the parent process via a DocumentChannel.
The aim of this task is two-fold.
1- Be consistent on how we handle redirects before continuing the load on the final channel.
2- Prepare to initiate a process switch when needed without having to go via an intermediary content process, saving a process switch. This task will be done in a follow-up task.
The behaviour of the ParentProcessDocumentChannel is similar in logic to the DocumentChannelChild/DocumentChannelParent pair. The ParentProcessDocumentChannel sets up a DocumentLoadListener, have it handle the redirects and upon completion continue the load on the final channel.
Differential Revision: https://phabricator.services.mozilla.com/D70009
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
This still doesn't really fix subframes, but those are broken in trunk
already.
Fixing subframes could be done by making the zoom Top()-only, or by
propagating to browsing contexts in the bfcache as well from DidSet(..).
Differential Revision: https://phabricator.services.mozilla.com/D72034
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
We have to add "IsThirdPartyWindow" in WindowContext because we need to know if
a BrowsingContext is third-party (The browsing context may be not
in-process).
Differential Revision: https://phabricator.services.mozilla.com/D71010
Add ParentProcessDocumentChannel object. This object is a DocumentChannel that will start a channel load from the parent process via a DocumentChannel.
The aim of this task is two-fold.
1- Be consistent on how we handle redirects before continuing the load on the final channel.
2- Prepare to initiate a process switch when needed without having to go via an intermediary content process, saving a process switch. This task will be done in a follow-up task.
The behaviour of the ParentProcessDocumentChannel is similar in logic to the DocumentChannelChild/DocumentChannelParent pair.
The ParentProcessDocumentChannel sets up a DocumentLoadListener, have it handle the redirects and upon completion continue the load on the final channel.
Differential Revision: https://phabricator.services.mozilla.com/D70009
Add ParentProcessDocumentChannel object. This object is a DocumentChannel that will start a channel load from the parent process via a DocumentChannel.
The aim of this task is two-fold.
1- Be consistent on how we handle redirects before continuing the load on the final channel.
2- Prepare to initiate a process switch when needed without having to go via an intermediary content process, saving a process switch. This task will be done in a follow-up task.
The behaviour of the ParentProcessDocumentChannel is similar in logic to the DocumentChannelChild/DocumentChannelParent pair.
The ParentProcessDocumentChannel sets up a DocumentLoadListener, have it handle the redirects and upon completion continue the load on the final channel.
Differential Revision: https://phabricator.services.mozilla.com/D70009
In this patch, we report the blocked node across the process
boundaries if the parent is in a different process. If the parent
document is in the same process as the reporting document, we
will directly add the blocked node in the parent document without
sending an IPC.
Differential Revision: https://phabricator.services.mozilla.com/D71939
In this patch, we report the blocked node across the process
boundaries if the parent is in a different process. If the parent
document is in the same process as the reporting document, we
will directly add the blocked node in the parent document without
sending an IPC.
Depends on D71938
Differential Revision: https://phabricator.services.mozilla.com/D71939
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
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
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
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
Nika Layzell
Peter Van der Beken
Noemi Erli
Sid Stamm
Csoregi Natalia
Dan Glastonbury
Nicklas Boman
alwu
Gijs Kruitbosch
Razvan Maries
Sebastian Streich
Bogdan Tara
Matt Woodrow
Marco Bonardo
Dorel Luca
Alexandre Poirot
Valentin Gosu
Christoph Kerschbaumer
Kashav Madan
Brindusan Cristian
Dana Keeler
David Teller
Narcis Beleuzu
Ian Moody
Emilio Cobos Álvarez
Cosmin Sabou
Jonathan Watt
stundets
Dimi Lee
Mike Conley
Jean-Yves Avenard
Steven MacLeod
Andrew McCreight
Andreas Farre
Sylvestre Ledru
Simon Giesecke
Arthur Iakab
Tim Nguyen
Andreea Pavel
Tim Huang
Stefan Hindli
Subhamoy Sengupta