This also fixes a bug where we were setting mOriginalUriString in docshell before InternalLoad (which clears it), instead of after.
Differential Revision: https://phabricator.services.mozilla.com/D80110
This is only used by Thunderbird, and is always true for Firefox. I've made CanSet only allow the embedder process, which is the desired behaviour, and should work for non-e10s.
Differential Revision: https://phabricator.services.mozilla.com/D80109
We shouldn't need to handle this with an early return in docshell, since the classifier failure codes won't display an error page anyway.
Differential Revision: https://phabricator.services.mozilla.com/D80108
I don't think we need these to be done at different times, since the set of checks that happen before uri fixup are error codes that won't be affected by fixup.
Differential Revision: https://phabricator.services.mozilla.com/D80107
This also fixes a bug where we were setting mOriginalUriString in docshell before InternalLoad (which clears it), instead of after.
Differential Revision: https://phabricator.services.mozilla.com/D80110
This is only used by Thunderbird, and is always true for Firefox. I've made CanSet only allow the embedder process, which is the desired behaviour, and should work for non-e10s.
Differential Revision: https://phabricator.services.mozilla.com/D80109
We shouldn't need to handle this with an early return in docshell, since the classifier failure codes won't display an error page anyway.
Differential Revision: https://phabricator.services.mozilla.com/D80108
I don't think we need these to be done at different times, since the set of checks that happen before uri fixup are error codes that won't be affected by fixup.
Differential Revision: https://phabricator.services.mozilla.com/D80107
This patch also makes the identifier for channels global, in the sense
that the generated identifier is generated outside of and passed to
the nsIRedirectChannelRegistrar.
Differential Revision: https://phabricator.services.mozilla.com/D79820
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
We can just use BrowsingContext::BrowserId directly, so it's unnecessary to have
the field on nsFrameLoaderOwner as well.
This also makes it so that we only ever generate browser IDs in
BrowsingContext::CreatedDetached.
Differential Revision: https://phabricator.services.mozilla.com/D80121
CLOSED TREE
Backed out changeset 8c4a24b91c88 (bug 1646088)
Backed out changeset ef746bdcbaf6 (bug 1646088)
Backed out changeset 77d15266af3c (bug 1646088)
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
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 adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
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
Due to the PPDC process switching changes, we also handle switching between
remote and non-remote browsers with DocumentLoadListener. Adds support to
CanonicalBrowsingContext::ChangeFrameRemoteness to allow it to handle non-remote
browsers as well.
Differential Revision: https://phabricator.services.mozilla.com/D78971
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
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One effect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
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
Due to the PPDC process switching changes, we also handle switching between
remote and non-remote browsers with DocumentLoadListener. Adds support to
CanonicalBrowsingContext::ChangeFrameRemoteness to allow it to handle non-remote
browsers as well.
Differential Revision: https://phabricator.services.mozilla.com/D78971
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
In order to delegate the permission to the top-level window, in this
patch, we pre-compute the permissions of the top-level context and set
them to the top-level WindowContext. So, the cross-origin iframe can
know the permission of the top-level window through the WindowContext.
Thus, the permission can be delegated in Fission.
Differential Revision: https://phabricator.services.mozilla.com/D79132
The first page's content viewer is only saved in the bfcache when the second
page is painted. This can happen after the load event is fired, and in that
scenario, attempting to go back to the first page will reload it rather than
restore it from the bfcache. So for the test to work properly it needs to
wait until the second page is actually painted before it attempts go back.
Differential Revision: https://phabricator.services.mozilla.com/D79347
This patch will
- remove `MediaControlKeysEvent` and use `MediaControlKey` to replace it
- rename names for all `MediaControlKey` related methods, functions, classes and descriptions
The advantage of doing so are
- remove the duplicated type so that we only need to maintain `MediaControlKey`
Differential Revision: https://phabricator.services.mozilla.com/D78140
This has the side effect of fixing support of mozallowfullscreen when
feature policy is enabled, because it checks only AllowFullscreen, which
doesn't check for the moz-prefixed attribute.
I left the swapframeloader bits alone because they're mozbrowser
specific and I have no idea what they're trying to do.
Differential Revision: https://phabricator.services.mozilla.com/D78701
Previously we called DisplayLoadError with NS_ERROR_DOM_BASE_URI for errors detected during AsyncOpen, but not for asynchronous errors, and this patch queue changed when some security errors happen to be asynchronous.
GeckoView has tests that require DisplayLoadError to be called (which allows for a custom error page to be loaded). Unfortunately, doing so breaks existing gecko tests, since the method of detecting a blocked load fails when GeckoView loads a custom error page.
Differential Revision: https://phabricator.services.mozilla.com/D77171
Adds a `browserId` property to all browsing contexts which the same for the
entire tree of contexts inside a frame element. If a new top-level context is
created for the frame then it is assigned the same value.
This allows identifying the frame element for a given browsing context.
Currently this is only done for XUL frame elements (browser/iframe). Not sure
if we want this for others.
Differential Revision: https://phabricator.services.mozilla.com/D56245
Previously we called DisplayLoadError with NS_ERROR_DOM_BASE_URI for errors detected during AsyncOpen, but not for asynchronous errors, and this patch queue changed when some security errors happen to be asynchronous.
GeckoView has tests that require DisplayLoadError to be called (which allows for a custom error page to be loaded). Unfortunately, doing so breaks existing gecko tests, since the method of detecting a blocked load fails when GeckoView loads a custom error page.
Differential Revision: https://phabricator.services.mozilla.com/D77171
Adds a `browserId` property to all browsing contexts which the same for the
entire tree of contexts inside a frame element. If a new top-level context is
created for the frame then it is assigned the same value.
This allows identifying the frame element for a given browsing context.
Currently this is only done for XUL frame elements (browser/iframe). Not sure
if we want this for others.
Differential Revision: https://phabricator.services.mozilla.com/D56245
It would otherwise triggers browser/base/content/test/performance/browser_preferences_usage.js
That pref would have been checked with every single load, a staticpref is O-1 .
Differential Revision: https://phabricator.services.mozilla.com/D76317
The moves all decisions to perform a process switch into the DocumentLoadListerner. This removes the unnecessary need to go via a content process to start the load.
Differential Revision: https://phabricator.services.mozilla.com/D76315
With recent fixes that can properly identify whitelisted domains, whitelisted
domain suffixed, valid known public suffixes, and forcing to visit URI-like
strings that end with a slash, it's time to re-evaluate the URIFixup behavior.
Until now URIFixup considered everything a URI unless it had specific search
characteristics, this patch inverts that behavior.
The scope of this change is to improve the urlbar behavior as the main Search
Access Point, since that's the direction we're moving towards.
This lands with a temporary hidden feature pref browser.fixup.defaultToSearch,
that will be removed once the feature has been released.
Differential Revision: https://phabricator.services.mozilla.com/D76852
This is mostly changes to handle retrieving the security state asynchronously via the parent process, needing lots of async/await additions.
It also removes the docshell mixed content flag checks (which don't seem to be used in code, only tests), which are mostly still covered by checks of the security UI.
Differential Revision: https://phabricator.services.mozilla.com/D75448
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
Previously we only set some fields as part of WindowGlobalInit, but WindowGlobalParent sets itself as the current window global on the CanonicalBrowsingContext.
This exposes a period of time where only part of the document state was set, and this was observable to consumers.
This makes OnNewDocument only run when there is a new Document for the same WindowGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D75446
This is mostly changes to handle retrieving the security state asynchronously via the parent process, needing lots of async/await additions.
It also removes the docshell mixed content flag checks (which don't seem to be used in code, only tests), which are mostly still covered by checks of the security UI.
Differential Revision: https://phabricator.services.mozilla.com/D75448
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
Previously we only set some fields as part of WindowGlobalInit, but WindowGlobalParent sets itself as the current window global on the CanonicalBrowsingContext.
This exposes a period of time where only part of the document state was set, and this was observable to consumers.
This makes OnNewDocument only run when there is a new Document for the same WindowGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D75446
This was a bit of pain to track down, because some code was allowing an ID of 0, and creating a request context to match, but other code was treating 0 as invalid.
Differential Revision: https://phabricator.services.mozilla.com/D76652
This changes the urlbar to always generate a result and then confirm it through
pickResult. This way we obtain a consistent behavior independently from whether
the view has a result or an action like Paste&Go happened.
Before this we used to go through getShortcutOrURIAndPostData, that implements
only a part of the urlbar logic, often causing different behavior depending on
the view state, and thus requiring constant maintenance to sync it up.
In a follow-up bug we will evaluate the complete removal of
getShortcutOrURIAndPostData in favor of direct calls to
UrlbarUtils.getHeuristicResultFor().
This also moves up a bit closer to always pass a final url to the docshell, and
stop trying to do complex URIFixup calls in it. For now we still rely
on its fix-ups for browser.fixup.dns_first_for_single_words, where we pass a
url, and if it's invalid it will instead search. See UrlbarUtils.RESULT_TYPE.URL
handling in pickResult().
Differential Revision: https://phabricator.services.mozilla.com/D75911
It would otherwise triggers browser/base/content/test/performance/browser_preferences_usage.js
That pref would have been checked with every single load, a staticpref is O-1 .
Differential Revision: https://phabricator.services.mozilla.com/D76317
The moves all decisions to perform a process switch into the DocumentLoadListerner. This removes the unnecessary need to go via a content process to start the load.
Differential Revision: https://phabricator.services.mozilla.com/D76315
This changes the urlbar to always generate a result and then confirm it through
pickResult. This way we obtain a consistent behavior independently from whether
the view has a result or an action like Paste&Go happened.
Before this we used to go through getShortcutOrURIAndPostData, that implements
only a part of the urlbar logic, often causing different behavior depending on
the view state, and thus requiring constant maintenance to sync it up.
In a follow-up bug we will evaluate the complete removal of
getShortcutOrURIAndPostData in favor of direct calls to
UrlbarUtils.getHeuristicResultFor().
This also moves up a bit closer to always pass a final url to the docshell, and
stop trying to do complex URIFixup calls in it. For now we still rely
on its fix-ups for browser.fixup.dns_first_for_single_words, where we pass a
url, and if it's invalid it will instead search. See UrlbarUtils.RESULT_TYPE.URL
handling in pickResult().
Differential Revision: https://phabricator.services.mozilla.com/D75911
Top-level content WindowGlobalParents now keep track of the site origins of the
documents in their document tree. When the WindowGlobalParent is torn down, the
maximum of the number of unique site origins is submitted for telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D71493
Previously we created a new request context id for each LoadGroup, which meant we didn't have a constant value across process switches.
The next patch uses this request context id when creating a new LoadGroup for an nsDocShell, so that all docshell/loadgroups for a BrowsingContext share the same id.
Differential Revision: https://phabricator.services.mozilla.com/D75884
Previously we created a new request context id for each LoadGroup, which meant we didn't have a constant value across process switches.
The next patch uses this request context id when creating a new LoadGroup for an nsDocShell, so that all docshell/loadgroups for a BrowsingContext share the same id.
Differential Revision: https://phabricator.services.mozilla.com/D75884
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
Reinstate customUserAgent interface for nsIDocShell. This is so it can be used
as a choke-point to catch setting values on docshells which are in the process
of changing process. We don't want to send changes which will be rejected on the
parent side.
This code should be removed once callers setting customUserAgent are refactored
to only occur from parent process.
Differential Revision: https://phabricator.services.mozilla.com/D75006
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
Nika Layzell
Matt Woodrow
Peter Van der Beken
Marco Bonardo
Gabriel Luong
Kris Maglione
Dorel Luca
Butkovits Atila
Olli Pettay
Henri Sivonen
Eden Chuang
Csoregi Natalia
Jared Wein
Andreas Farre
Jean-Yves Avenard
Narcis Beleuzu
Kashav Madan
tkhan
Christoph Kerschbaumer
Mihai Alexandru Michis
Razvan Maries
Nicholas Nethercote
Dave Townsend
Simon Giesecke
Bogdan Tara
julianwels
Emilio Cobos Álvarez
Logan Smyth
Tim Huang
Kartikaya Gupta
Johann Hofmann
Tom Tung
alwu
Anny Gakhokidze
Andrea Marchesini
Gijs Kruitbosch
Noemi Erli
Jonathan Kingston
Masatoshi Kimura
Erica Wright
Barret Rennie
Sid Stamm
Dan Glastonbury
Nicklas Boman
Sebastian Streich