This patch installs the framework for various platforms to inform the user of
one of two things: 1) a coming system dialog asking for system geolocation
permission that will be presented after the Firefox doorhanger asking for
permission for the page, and 2) that we will open a system preferences window,
where the user can enable geolocation for Firefox because it is currently not
enabled. The code that handles this has been remoted to the parent process
since implementations will not be able to operate in the content process
sandbox.
Here, it stubs the behavior so this does nothing on every platform.
In this patch series, the behavior will be implemented for Windows.
Note: The code will run the geolocation for the page if the user granted it in
Firefox, regardless of whether the user granted or canceled the system
permission. This respects the user's instruction and provides a work-around in
the event of a bug, although it would usually either fail to get a location or
it will get a very poor one (e.g. via IP lookup).
Differential Revision: https://phabricator.services.mozilla.com/D216473
There are many other uses of OtherPid which could be switched over to
OtherChildID, but these were a couple of obvious low-hanging fruit use-cases
which will work better when using OtherChildID.
Differential Revision: https://phabricator.services.mozilla.com/D217120
The type for ContentParentId is uint64_t, however only at most 22 bits
are allowed to be used (as it is used in the high bits of nsContentUtils
process-specific IDs, which need to fit within a JS double). Switching to use
the same existing ChildID reduces the risk of confusion, but this patch doesn't
attempt to update the types used for ContentParentId/ChildID to match
GeckoChildID.
In the future, we probably will want to align these types more closely, and
perhaps de-duplicate some code which currently passes around both.
Differential Revision: https://phabricator.services.mozilla.com/D217119
This requires quite a bit of piping to get the ChildID passed everywhere where
we currently pass the pid in IPC. This is done by adding a new struct type
(EndpointProcInfo), which is passed around instead of OtherPid in these places,
and contains the full pid.
In most cases, it was a fairly painless change to move over, however in some
cases, more complex changes were required, as the pid was being stored
previously in something like an Atomic<...>, and needed to be switched to using
a mutex-protected value.
In the future, it may be possible to remove OtherPid from IPDL actors once
everything is migrated to ChildID, but we're still a long way off from that, so
for now we unfortunately need to pass both around.
Differential Revision: https://phabricator.services.mozilla.com/D217118
Previously this load would be allowed due to the "web-controlled" check
failing to reject the load. This patch instead bases it on the
docshell.newWindowTarget flag, which is set for the first load in a new
DocShell due to a call to window.open or target=_blank.
This required making the external protocol channel be a property bag so
that the flag can be set on the channel. In the future we may want to
switch this flag to being set in a more generic way which is less
specific to the channel.
Differential Revision: https://phabricator.services.mozilla.com/D217484
Previously this load would be allowed due to the "web-controlled" check
failing to reject the load. This patch instead bases it on the
docshell.newWindowTarget flag, which is set for the first load in a new
DocShell due to a call to window.open or target=_blank.
This required making the external protocol channel be a property bag so
that the flag can be set on the channel. In the future we may want to
switch this flag to being set in a more generic way which is less
specific to the channel.
Differential Revision: https://phabricator.services.mozilla.com/D217484
* Allow mocking DAPTelemetrySender to test measurements without having
to decrypt payloads
* Allow mocking Date.now to test expiration conditions
Also:
* Stop swallowing errors in DAPTelemetrySender
* Correct typo loopbackDays -> lookbackDays
Differential Revision: https://phabricator.services.mozilla.com/D212957
Given meta/ctrl key should use browser.tabs.loadInBackground pref instead of
browser.tabs.loadDivertedInBackground pref, the existing
nsIBrowserDOMWindow.OPEN_NEWTAB behavior doesn't match the requirement.
Add dedicate flag for "open in foreground tab" to make it controllable from
nsWindowWatcher::IsWindowOpenLocationModified.
Differential Revision: https://phabricator.services.mozilla.com/D201929
nsBaseDragService keeps track of the processes that might need to cancel a drag with EndDragSession and this is technically correct since the drag session is a singleton in the child process, but this series of patches changes those sessions to be per-PuppetWidget/BrowserChild. This allows content processes to distinguish which of its browsers is engaged in a drag.
Differential Revision: https://phabricator.services.mozilla.com/D211062
Updates each client of the nsContentUtils method to get the right drag session -- the one for the widget that is currently the source or target of the drag session.
The change to nsDOMWindowUtils::DispatchDOMEventViaPresShellForTesting() supports the change to WidgetDragEvent::InitDropEffectForTests() and enabled a
large number of test fixes in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D211067
* Allow mocking DAPTelemetrySender to test measurements without having
to decrypt payloads
* Allow mocking Date.now to test expiration conditions
Also:
* Stop swallowing errors in DAPTelemetrySender
* Correct typo loopbackDays -> lookbackDays
Differential Revision: https://phabricator.services.mozilla.com/D212957
The code path that was used for loading a document
with fission disabled did not take user activation into account.
This made almost all WPTs for Text Fragments fail,
since they depend on this flag to decide if
a text directive is allowed to be scrolled to.
This patch makes sure that the user activation is
also available for code paths that run through
`CanonicalBrowsingContext::FixupAndLoadURIString()`
to load a document.
This is done by adding a flag `hasValidUserGestureActivation`
to the `nsIOpenWindowInfo`, which carries it through
the JS stack for loading a document.
Differential Revision: https://phabricator.services.mozilla.com/D213401
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
This shouldn't change behaviour, as the default JS MinTabSelector's behaviour
should roughly match the C++ one. The selector will be updated in a later
patch.
A new pref has been added to disable content process re-use which to replace
the test-only use-case for replacing the process selector.
Differential Revision: https://phabricator.services.mozilla.com/D213336
This logic did nothing in Fission, however it did have an effect for
e10s-Android, which will no longer have process recycling. I expect the impact
of this to be minimal given Android's tendency to kill processes already.
This feature is being removed because supporting the recycling approach with
the new KeepAlive system being added in future patches would've added
complexity for a largely-unsupported configuration.
Differential Revision: https://phabricator.services.mozilla.com/D213335
This enables the PRemoteWorkerService to be created by the parent process
instead of by the content process, which is useful as the parent process is the
party initiating remote worker actions.
Differential Revision: https://phabricator.services.mozilla.com/D213333
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
This shouldn't change behaviour, as the default JS MinTabSelector's behaviour
should roughly match the C++ one. The selector will be updated in a later
patch.
A new pref has been added to disable content process re-use which to replace
the test-only use-case for replacing the process selector.
Differential Revision: https://phabricator.services.mozilla.com/D213336
This logic did nothing in Fission, however it did have an effect for
e10s-Android, which will no longer have process recycling. I expect the impact
of this to be minimal given Android's tendency to kill processes already.
This feature is being removed because supporting the recycling approach with
the new KeepAlive system being added in future patches would've added
complexity for a largely-unsupported configuration.
Differential Revision: https://phabricator.services.mozilla.com/D213335
This enables the PRemoteWorkerService to be created by the parent process
instead of by the content process, which is useful as the parent process is the
party initiating remote worker actions.
Differential Revision: https://phabricator.services.mozilla.com/D213333
The code path that was used for loading a document
with fission disabled did not take user activation into account.
This made almost all WPTs for Text Fragments fail,
since they depend on this flag to decide if
a text directive is allowed to be scrolled to.
This patch makes sure that the user activation is
also available for code paths that run through
`CanonicalBrowsingContext::FixupAndLoadURIString()`
to load a document.
This is done by adding a flag `hasValidUserGestureActivation`
to the `nsIOpenWindowInfo`, which carries it through
the JS stack for loading a document.
Differential Revision: https://phabricator.services.mozilla.com/D213401
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
This shouldn't change behaviour, as the default JS MinTabSelector's behaviour
should roughly match the C++ one. The selector will be updated in a later
patch.
A new pref has been added to disable content process re-use which to replace
the test-only use-case for replacing the process selector.
Differential Revision: https://phabricator.services.mozilla.com/D213336
This logic did nothing in Fission, however it did have an effect for
e10s-Android, which will no longer have process recycling. I expect the impact
of this to be minimal given Android's tendency to kill processes already.
This feature is being removed because supporting the recycling approach with
the new KeepAlive system being added in future patches would've added
complexity for a largely-unsupported configuration.
Differential Revision: https://phabricator.services.mozilla.com/D213335
This enables the PRemoteWorkerService to be created by the parent process
instead of by the content process, which is useful as the parent process is the
party initiating remote worker actions.
Differential Revision: https://phabricator.services.mozilla.com/D213333
When sync IPC under the top-level PCompositorManager protocol does not
reply within a certain time threshold we purposefully kill the GPU
process. While this allows the user to recover from a stuck GPU
process, we have little visibility about the underlying cause.
This patch makes it so that we generate a paired minidump for the GPU
and parent processes prior to killing the GPU process in
GPUProcessHost::KillHard(). The implementation roughly follows the
equivalent for content processes in ContentParent::KillHard().
As the GPU process can be purposefully killed during normal operation,
and because generating minidumps can be expensive, we are careful to
only do so when the new argument aGenerateMinidump is true. We
additionally remove the aReason argument as it is unused (and
currently innacurate in some places).
As these minidumps may not automatically submitted we limit the
minidumps generation to twice per session in order to avoid
accumulating a large number of unsubmitted minidumps on disk.
Differential Revision: https://phabricator.services.mozilla.com/D202166
