This works, though probably we want to do some follow-up tweaks, like
the adding of the onload blocker and so on, so that we can avoid the
UpdateDimensions hack.
We may also want a PrintObject in the nsPrintJob tree, perhaps...
Differential Revision: https://phabricator.services.mozilla.com/D90310
Now requesting/releasing pointer lock in content process will send IPC to let
parent process know which content process request a lock, so parent process
could dispatch mouse event to the right content process. And if there is already
a content proess had a lock, parent process will reject lock request from other
content proesses.
Differential Revision: https://phabricator.services.mozilla.com/D90313
To force navigation to block on the long running script it needs to be
loading a page on the same domain as the blocking script, otherwise
fission and Session history in the parent will happily change
remoteness to another process and load immediately.
Depends on D90825
Differential Revision: https://phabricator.services.mozilla.com/D90826
Now requesting/releasing pointer lock in content process will send IPC to let
parent process know which content process request a lock, so parent process
could dispatch mouse event to the right content process. And if there is already
a content proess had a lock, parent process will reject lock request from other
content proesses.
Differential Revision: https://phabricator.services.mozilla.com/D90313
This requires adding the flag as a synced field on the BrowsingContext, and
checking it in a few more places. Attempts to open a new window in this racy
manner will now raise an exception.
This should avoid the issue from bug 1658854 by blocking the buggy attempts to
load before the nested event loop has been exited.
Differential Revision: https://phabricator.services.mozilla.com/D87927
This has couple of different pieces and one may want to focus on each of those separately when
reviewing. The first two as small changes.
- Moving mDynamicallyCreated from nsDocShell to be a sync'ed field on BrowsingContext.
CanonicalBrowsingContext::CreateLoadingSessionHistoryEntryForLoad sets that on a newly created entry.
- Adding mActiveEntryIsLoadingFromSessionHistory. mLoadingEntry + mActiveEntryIsLoadingFromSessionHistory has roughly
the same lifetime as mLSHE. mLoadingActiveEntry is needed so that child docshell can know whether its parent is loading from session history.
- The main part is in MaybeHandleSubframeHistory which checks if the parent docshell is loading from session history,
and if so, asks for a LoadingSessionHistoryInfo. In the case of docshell living in a child process that operation is asynchronous,
so when the data is back from the parent process, LoadURI is called again with the possibly updated data.
One could possibly split the code to smaller methods and then deal with aContinueHandlingSubframeHistory only in LoadURI,
but MaybeHandleSubframeHistory does have some early returns which would make that approach possibly hard to follow.
Differential Revision: https://phabricator.services.mozilla.com/D89685
ChildSHistory.legacySHistory isn't valid for content processes when
session history in the parent is enabled. We try to fix this by either
delegating to the parent by IPC or move the implementation partially
or as a whole to the parent.
Differential Revision: https://phabricator.services.mozilla.com/D89353
This backs out all work from bug 1627075 as well as all of its
descendents. There were a few conflicts when backing this out but
overall it was pretty clean, so I would say it's a fairly mild
level of risk. Historically Nathan Froyd has reviewed these patches,
but he is no longer at Mozilla, and no one else is particularly
familiar with the code, so I am passing this off to RyanVM who has
at least been familiar with the history of the bug.
Differential Revision: https://phabricator.services.mozilla.com/D90096
Mostly mechanical changes, with some work needed to convert the different payloads (with optional timestamps, inner window id, and/or backtrace) to the equivalent MarkerOptions.
Differential Revision: https://phabricator.services.mozilla.com/D89587
Various tests disable process preallocation in order to get "stable" process
counts for testing purposes. In order to keep this behaviour, we need to disable
and shut down the recycled E10S process whenever the preallocator is disabled.
This is accomplished by having the preallocator expose its enabled status to
ContentParent, and by having the preallocator trigger ContentParent shutdown
when it is disabled.
This also has the benefit of hooking the recycler back into memory pressure
notifications, meaning it will be shut down if not in use when a memory pressure
event occurs.
Differential Revision: https://phabricator.services.mozilla.com/D88628
This helper method abstracts over the common tasks performed in every normal
shutdown codepath. This will be useful for making process recycling respect
preallocation being disabled.
Differential Revision: https://phabricator.services.mozilla.com/D88627
It is uncommon to have long-lived "web" processes when Fission is enabled, so in
general we probably don't want to be performing content process recycling.
We also skip recycling web processes when E10s is disabled, as the process
preallocator would be disabled in that case, so recycling processes can lead to
mochitest-chrome test failures.
Differential Revision: https://phabricator.services.mozilla.com/D88626
Previously, we would use the PreallocatedProcessManager to handle recycled
"web" content processes, which would remove them from the pool and try to make
them act like "prealloc" content processes.
Unlike true preallocated content processes, we can end up having content loaded
in recycled "web" content processes, such as due to a new pop-up being created
at an inconvenient time during process teardown. The complexity around this
semi-prealloc state caused some assertion failures in other related code.
This new approach doesn't remove the recycled process from the process selection
pool. Instead, after process selection decides to spawn a new "web" process, a
pointer to the specific "recycled" content process is fetched and returned by
the process selection algorithm before asking the preallocator.
This new approach should have similar behaviour, but avoids some of the pitfalls
caused by removing the entry from the process selection pool after it has begun
hosting content.
Differential Revision: https://phabricator.services.mozilla.com/D88625
APZ can sometimes indicate that it will be consuming touch events, even though
the touch-action properties prohibit it. This can happen if, for example, APZ
is waiting on the main-thread for accurate touch-action information. In such
cases, the main thread has enough information to filter out these false positives.
This patch makes it do that, by plumbing the allowed touch behaviors into
the APZEventState code that triggers the pointercancel event.
Differential Revision: https://phabricator.services.mozilla.com/D89303
We don't know why we see initialization failures in the telemetry which
makes it hard to investigate why users aren't getting WebRender and
instead fallback to basic. Let's expose the detailed error message
WebRender already generates and puts in the critical log.
Differential Revision: https://phabricator.services.mozilla.com/D89185
As much as I hate nested event loops, I think we need to do it for this
case :)
Hopefully print() already assumes nested event loops can happen because
of the native dialog so it's already properly set up for this.
Differential Revision: https://phabricator.services.mozilla.com/D89254
Christoph Kerschbaumer
Olli Pettay
Nico Grunbaum
Kris Maglione
Emilio Cobos Álvarez
Mihai Alexandru Michis
Edgar Chen
Andreas Farre
Cameron McCormack
Narcis Beleuzu
Peter Van der Beken
Dorel Luca
Nika Layzell
Bianca Danforth
Barret Rennie
Andrea Marchesini
Doug Thayer
Agi Sferro
Bogdan Tara
Mark Banner
Gerald Squelart
Razvan Maries
Kartikaya Gupta
Andrew Osmond