This patch adds a blank page about:third-party along with a skeleton XPCOM
object AboutThirdParty which has a method to invoke a background task in C++.
Differential Revision: https://phabricator.services.mozilla.com/D109303
This patch adds a blank page about:third-party along with a skeleton XPCOM
object AboutThirdParty which has a method to invoke a background task in C++.
Differential Revision: https://phabricator.services.mozilla.com/D109303
This should help avoid crashes caused when the content process has
already destroyed a BCG when the parent process hasn't yet. The BCG will
still be destroyed when the content process shuts down using normal
cycle-collection.
Differential Revision: https://phabricator.services.mozilla.com/D113828
Use the newly added session storage data getter to access the session
storage in the parent and store it in session store without a round
trip to content processes.
Depends on D111433
Differential Revision: https://phabricator.services.mozilla.com/D111434
This allows loads to be tracked as they are ongoing on a per-context basis in
the parent process, and for events to be generated for each subframe as it is
destroyed.
This patch also stops sending the `IsLoadingDocument` flag on the request to
the main process and removes RemoteWebProgress, as they are no longer necessary
due to being tracked directly.
Finally this patch also adds some logging to BrowsingContextWebProgress
to make it easier to diagnose this type of issue in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115706
This allows loads to be tracked as they are ongoing on a per-context basis in
the parent process, and for events to be generated for each subframe as it is
destroyed.
This patch also stops sending the `IsLoadingDocument` flag on the request to
the main process and removes RemoteWebProgress, as they are no longer necessary
due to being tracked directly.
Finally this patch also adds some logging to BrowsingContextWebProgress
to make it easier to diagnose this type of issue in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115706
Use the newly added session storage data getter to access the session
storage in the parent and store it in session store without a round
trip to content processes.
Depends on D111433
Differential Revision: https://phabricator.services.mozilla.com/D111434
We strip the target query parameters in BrowsingContext::LoadURI(). This
is needed for the loading from the RemoteWebNavigation. The parent
process will create the channel before the loading happens in the
nsDocShell in content process. So we have to strip before the channel
has been created in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D113844
The target query parameters will be stripped from the loading URI in
nsDocShell before creating the channel for the loading. We will only
strip the URI for top-level loading but not for frames. It's because
there is no need to strip frames if we've stripped in top-level already.
Differential Revision: https://phabricator.services.mozilla.com/D113843
This should help avoid crashes caused when the content process has
already destroyed a BCG when the parent process hasn't yet. The BCG will
still be destroyed when the content process shuts down using normal
cycle-collection.
Differential Revision: https://phabricator.services.mozilla.com/D113828
Running AssertDocGroupMatchesKey() on an unlinked document can cause
a crash in debug builds, so pass in the group directly, because all
of the callers are Documents so they already have it.
Differential Revision: https://phabricator.services.mozilla.com/D115272
With Fission, there can be multiple BrowserParents in a single tab, so
this patch moves the tracking of active tabs onto the top BrowsingContext
in a tab. If the priority of a top BC is changed, then the activity
of all of the BPs of the BCs in the tree are all adjusted. The flag
that tracks this state gets carried forward to the new BC in the case
of a cross-group navigation by the changes in ReplacedBy().
The other change here covers the case where we do a process-switching
navigation on an iframe. If we create a new BrowserParent with an active
top BC, then the BP gets marked as active in the priority manager. Doing
this tracking on the BP instead of the BC (both here in and in the part
that landed previously in BrowserParent::Deactivated()) means that we
don't need to track down every place that a BC switches processes.
I left the tracking of activity in ParticularProcessPriorityManager
centered around BrowserParents, instead of changing it to BCs, to
minimize the changes required. There are some tricky interactions there
with wakelocks that I didn't want to have to figure out.
browser_ProcessPriorityManager.js was set up to track a mapping of
browsers to priorities, but for the purposes of testing Fission support
I changed it to track a mapping of child IDs to priorities.
In the test, I also removed an assignment (this.window = null) that
didn't seem to be doing anything.
Differential Revision: https://phabricator.services.mozilla.com/D112213
This should help avoid crashes caused when the content process has
already destroyed a BCG when the parent process hasn't yet. The BCG will
still be destroyed when the content process shuts down using normal
cycle-collection.
Differential Revision: https://phabricator.services.mozilla.com/D113828
With Fission, there can be multiple BrowserParents in a single tab, so
this patch moves the tracking of active tabs onto the top BrowsingContext
in a tab. If the priority of a top BC is changed, then the activity
of all of the BPs of the BCs in the tree are all adjusted. The flag
that tracks this state gets carried forward to the new BC in the case
of a cross-group navigation by the changes in ReplacedBy().
The other change here covers the case where we do a process-switching
navigation on an iframe. If we create a new BrowserParent with an active
top BC, then the BP gets marked as active in the priority manager. Doing
this tracking on the BP instead of the BC (both here in and in the part
that landed previously in BrowserParent::Deactivated()) means that we
don't need to track down every place that a BC switches processes.
I left the tracking of activity in ParticularProcessPriorityManager
centered around BrowserParents, instead of changing it to BCs, to
minimize the changes required. There are some tricky interactions there
with wakelocks that I didn't want to have to figure out.
browser_ProcessPriorityManager.js was set up to track a mapping of
browsers to priorities, but for the purposes of testing Fission support
I changed it to track a mapping of child IDs to priorities.
In the test, I also removed an assignment (this.window = null) that
didn't seem to be doing anything.
Differential Revision: https://phabricator.services.mozilla.com/D112213
nsFrameLoaderOwner::ReplaceFrameLoader calls nsFocusManager::ActivateRemoteFrameIfNeeded.
If the call to nsFrameLoaderOwner::ReplaceFrameLoader happens before the BC is marked as
not in BFCache, then the focus manager will not fire focus events because the window is
still frozen.
Differential Revision: https://phabricator.services.mozilla.com/D114227
This should help avoid message ordering issues in the next patches. To ensure
that we're not firing events too early, we now do a "full" restore even if we
don't have form or scroll data, including for about:blank URIs.
This also moves all restore state on the CanonicalBrowsingContext into a
separate `mRestoreState` struct.
Differential Revision: https://phabricator.services.mozilla.com/D110333
This also fixes test
browser/base/content/test/tabs/browser_navigate_through_urls_origin_attributes.js
which was failing for fission + bfcacheInParent, because about:privatebrowsing
was getting bfcached, and an extra XULFrameLoaderCreated event was firing, when
we were not expecting it.
Differential Revision: https://phabricator.services.mozilla.com/D112441
This should help avoid message ordering issues in the next patches. To ensure
that we're not firing events too early, we now do a "full" restore even if we
don't have form or scroll data, including for about:blank URIs.
This also moves all restore state on the CanonicalBrowsingContext into a
separate `mRestoreState` struct.
Differential Revision: https://phabricator.services.mozilla.com/D110333
The test is using a framescript to have an observer for "http-on-opening-request".
That is used for the actual testpage but we need to prevent the next page to enter bfcache, so that
when going back from the session history frameloader isn't changed.
So in this case disabling bfcache should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D112245
This removes some sketchy non-caching of cursors on windows while at it,
now that plugins are gone, but otherwise shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D112475
This makes it trivial to choose the right BrowserParent to print a
browsing context, by removing the OuterWindowID / FrameLoader
indirections.
Differential Revision: https://phabricator.services.mozilla.com/D112412
Critically, this makes sure SubDialog.abort calls SubDialog.close even if its contents haven't finished
loading. This prevents a shutdown leak.
Differential Revision: https://phabricator.services.mozilla.com/D111736
Otherwise when navigating to a replaced browsing context we might have
an incorrect "is single top-level in history".
Fixes test_window_close.html with Fission+bfcache.
Differential Revision: https://phabricator.services.mozilla.com/D111458
Also, make sure we update layout history state from docshell before we load a
new URI, as it might be our last chance to do so before a process swap.
Differential Revision: https://phabricator.services.mozilla.com/D110994
Otherwise when navigating to a replaced browsing context we might have
an incorrect "is single top-level in history".
Fixes test_window_close.html with Fission+bfcache.
Differential Revision: https://phabricator.services.mozilla.com/D111458
Just like how for window.open() it's checked on the opener, of course.
Note that when sending the focus request via IPC, we trust the check
done on the child (bug 1677899).
Do we have a good test to extend to cover this case?
Differential Revision: https://phabricator.services.mozilla.com/D111107
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
Removes the PluginProvider and NPAPI plugin blocklist handling as part of removing all NPAPI support. This allows us to remove nsIPluginHost.
Differential Revision: https://phabricator.services.mozilla.com/D107148
This also fixes links in top or in-process subframes and out-of-process subframes in extensions sidebars and panels so that they open in new tabs.
Differential Revision: https://phabricator.services.mozilla.com/D110102
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
Removes the PluginProvider and NPAPI plugin blocklist handling as part of removing all NPAPI support. This allows us to remove nsIPluginHost.
Differential Revision: https://phabricator.services.mozilla.com/D107148
This was somewhat convoluted to get to both reliably reproduce and not timeout
after the fixes were applied. The test can't run without Fission, as it
requires a process switch to occur on the navigation to/from
http://example.com.
Without part 2 of this patch stack, this test will crash after the process
switch.
Differential Revision: https://phabricator.services.mozilla.com/D110003
This patch contains a large number of changes around the process switching
mechanism in order to avoid issues which are caused by a mismatched
understanding of the state of the process switch between processes in the
presence of nested event loops.
This includes:
1. The "InFlightProcessId" value is no longer recorded. All remaining uses
were removed in part 1, and the new mechanism tracks this information in
a better way.
2. The current BrowserParent instance is now tracked on
CanonicalBrowsingContext, meaning that logic which needs to work with this
information can now access it without depending on the current
WindowGlobalParent instance.
3. When doing a process switch, the previous host process for the
BrowsingContext is tracked until the process switch is completed, allowing
for future attempts to switch into that process to be delayed until the
previous unload event has finished running.
4. The process switch logic was refactored to simplify some of the
error-handling logic, and share more code between different cases.
Differential Revision: https://phabricator.services.mozilla.com/D110002
This is necessary as in part 2 the InFlightProcessId value will no longer be
tracked, so any remaining code which depends on it needs to be removed.
Differential Revision: https://phabricator.services.mozilla.com/D110001
This was somewhat convoluted to get to both reliably reproduce and not timeout
after the fixes were applied. The test can't run without Fission, as it
requires a process switch to occur on the navigation to/from
http://example.com.
Without part 2 of this patch stack, this test will crash after the process
switch.
Differential Revision: https://phabricator.services.mozilla.com/D110003
This patch contains a large number of changes around the process switching
mechanism in order to avoid issues which are caused by a mismatched
understanding of the state of the process switch between processes in the
presence of nested event loops.
This includes:
1. The "InFlightProcessId" value is no longer recorded. All remaining uses
were removed in part 1, and the new mechanism tracks this information in
a better way.
2. The current BrowserParent instance is now tracked on
CanonicalBrowsingContext, meaning that logic which needs to work with this
information can now access it without depending on the current
WindowGlobalParent instance.
3. When doing a process switch, the previous host process for the
BrowsingContext is tracked until the process switch is completed, allowing
for future attempts to switch into that process to be delayed until the
previous unload event has finished running.
4. The process switch logic was refactored to simplify some of the
error-handling logic, and share more code between different cases.
Differential Revision: https://phabricator.services.mozilla.com/D110002
This is necessary as in part 2 the InFlightProcessId value will no longer be
tracked, so any remaining code which depends on it needs to be removed.
Differential Revision: https://phabricator.services.mozilla.com/D110001
The other navigation that allows focus moves (window.open) already goes
through the popup blocker, so that one is fine.
I think given how weird yet conservative other browsers are, this should
be a good trade-off to avoid false positives.
Differential Revision: https://phabricator.services.mozilla.com/D110196
Similarly to the old session history implementation, scroll position needs to be stored in HandleSameDocumentNavigation.
The relevant old implementation is couple of lines above the new code in nsDocShell.
Differential Revision: https://phabricator.services.mozilla.com/D109756
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
The extension framework needs to set specific flags on navigations triggered
by meta refresh headers. Adding this to the load type of all navigations
triggered by meta refreshes allows it to do this without tracking docshells on
which refreshes are attempted so that it can make inferences.
Differential Revision: https://phabricator.services.mozilla.com/D108726
The naming scheme references the hashchange event. This is required by the
extensions framework to call the appropriate navigation listeners when only
the reference fragment is updated by a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D108725
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
Theoretically this change shouldn't be necessary, however frequent
intermittents suggest that there are still cases where holding a strong
reference here can lead to memory leaks.
Differential Revision: https://phabricator.services.mozilla.com/D109445
The extension framework needs to set specific flags on navigations triggered
by meta refresh headers. Adding this to the load type of all navigations
triggered by meta refreshes allows it to do this without tracking docshells on
which refreshes are attempted so that it can make inferences.
Differential Revision: https://phabricator.services.mozilla.com/D108726
The naming scheme references the hashchange event. This is required by the
extensions framework to call the appropriate navigation listeners when only
the reference fragment is updated by a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D108725
Implement an observer to wait for correct window events in order to restore tab
content. Non-SHIP code restores about:reader scroll position after receiving
"AboutReaderContentReady" event, so to achieve the same thing with session
history in parent enabled, we can wait for "AboutReader:Ready" event.
Differential Revision: https://phabricator.services.mozilla.com/D108712
The extension framework needs to set specific flags on navigations triggered
by meta refresh headers. Adding this to the load type of all navigations
triggered by meta refreshes allows it to do this without tracking docshells on
which refreshes are attempted so that it can make inferences.
Differential Revision: https://phabricator.services.mozilla.com/D108726
The naming scheme references the hashchange event. This is required by the
extensions framework to call the appropriate navigation listeners when only
the reference fragment is updated by a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D108725
The patch makes HistoryTracker rely on SHEntrySharedParentState instead of nsSHEntryShared.
nsSHEntryShared already extends SHEntrySharedParentState.
The test was modified a tiny bit to make it easier to see the results. The test does pass
with SHIP+BFCache.
Depends on D108851
Differential Revision: https://phabricator.services.mozilla.com/D108984
The old setup is a tad fragile since it relies on Stop to happen at a particular moment.
The name RefreshURIToQueue is just trying to be consistent with RefreshURIFromQueue
Differential Revision: https://phabricator.services.mozilla.com/D107930
Previously, the DocGroup type was not cycle-collected, as it needed to have
references from other threads for Quantum DOM. Nowadays the only off-main-thread
use of DocGroup is for dispatching runnables to the main thread which should be
tracked using a performance counter for about:performance. This means we can
remove the DocGroup references from these dispatching callsites, only storing
the Performance Counter we're interested in, and simplify make DocGroup be
cycle-collected itself.
This fixes a leak caused by adding the WindowGlobalChild getter to
WindowContext, by allowing cycles between the document and its BrowsingContext
to be broken by the cycle-collector.
Differential Revision: https://phabricator.services.mozilla.com/D108865
This should further reduce the chance that a BrowsingContextGroup is mentioned
in a message which has already ben destroyed by a remote process.
Differential Revision: https://phabricator.services.mozilla.com/D108121
This allows for the WindowGlobalChild getter in WindowContext to be acquired
more efficiently without performing hashtable lookups, and should generally
simplify things.
The patch also removes the unnecessary XRE_IsContentProcess assertions, and
removes the global hashtable for tracking WindowGlobalChild instances which is
no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D108120
The issues with BrowsingContextGroup identity may be related to using a
destroyed BrowsingContextGroup in some situations when we shouldn't be. By
upgrading the intensity of these assertions, we should be able to catch the
issues more readily.
Differential Revision: https://phabricator.services.mozilla.com/D108117
The extension framework needs to set specific flags on navigations triggered
by meta refresh headers. Adding this to the load type of all navigations
triggered by meta refreshes allows it to do this without tracking docshells on
which refreshes are attempted so that it can make inferences.
Differential Revision: https://phabricator.services.mozilla.com/D108726
The naming scheme references the hashchange event. This is required by the
extensions framework to call the appropriate navigation listeners when only
the reference fragment is updated by a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D108725
Note that this does not change `AllowPlugins` (because it is going away soon)
or `HasMainMediaController` (because don't know the code well enough to be
confident that reverting it would be safe), but does fix all other callers.
Differential Revision: https://phabricator.services.mozilla.com/D107704
Butkovits Atila
Toshihito Kikuchi
Nika Layzell
Andreas Farre
Csoregi Natalia
Niklas Goegge
Olli Pettay
Alexandru Michis
Andreea Pavel
Tim Huang
Dorel Luca
Anny Gakhokidze
Andrew McCreight
Mike Conley
Brindusan Cristian
Peter Van der Beken
Kris Maglione
Edgar Chen
Narcis Beleuzu
Sandor Molnar
Noemi Erli
Kashav Madan
Valentin Gosu
Daisuke Akatsuka
Henri Sivonen
Joel Maher
Emilio Cobos Álvarez
Masatoshi Kimura
Hubert Boma Manilla
Christoph Kerschbaumer
lyavor
David Parks
Neil Deakin
Cosmin Sabou
Bogdan Tara
Simon Giesecke
ankur
Mark Banner
Eden Chuang