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 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
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
We only use the contentBlockingAllowListPrincipal for excluding sites from content
blocking for top level documents. We don't need it in the content process and should
not compute it for every document.
Differential Revision: https://phabricator.services.mozilla.com/D100781
Syncing the container FeaturePolicy across BrowsingContext is actually
a bit more heavy-handed than necessary. We only ever need a container
FeaturePolicy when inheriting a FeaturePolicy in exactly the document
the container contains. Not every process that the tree the container
is a part of. So instead of storing a FeaturePolicy in a synced field,
we manually send it to the correct WindowGlobalChild (which
corresponds to a document) and retrieve it from there.
Differential Revision: https://phabricator.services.mozilla.com/D61479
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
When a page doesn't have a non-empty media session metadata, we would use its title as a default metadata, which would display as an artist name on the virtual control interface.
Therefore, when a page changes its title, we should also notify media controller (if it's been created) in order to update the default metadata as well.
Differential Revision: https://phabricator.services.mozilla.com/D93670
This changes the way we deal with page use counters so that we can
handle out of process iframes.
Currently, when a parent document is being destroyed, we poke into all
of the sub-documents to merge their use counters into the parent's page
use counters, which we then report via Telemetry. With Fission enabled,
the sub-documents may be out of process. We can't simply turn these
into async IPC calls, since the parent document will be destroyed
shortly, as might the content processes holding the sub-documents.
So instead, each document during its initialization identifies which
ancestor document it will contribute its page use counters to, and
stores its WindowContext id to identify that ancestor. A message is
sent to the parent process to notify it that page use counter data will
be sent at some later point. That later point is when the document
loses its window. It doesn't matter if the ancestor document has
already been destroyed at this point, since all we need is its
WindowContext id to uniquely identify it. Once the parent process has
received all of the use counters it expects to accumulate to a given
WindowContext Id, it reports them via Telemetry.
Reporting of document use counters remains unchanged and is done by each
document in their content process.
While we're here, we also:
* Limit use counters to be reported for a pre-defined set of document
URL schemes, rather than be based on the document principal.
* Add proper MOZ_LOG logging for use counters instead of printfs.
Differential Revision: https://phabricator.services.mozilla.com/D87188
We would like to remove `page_had_media_count` and use a new probe `in_page_count` to record the total number of top level content documents using media.
Therefore, we would rename WindowContext's `DocTreeHadAudibleMedia` to `DocTreeHadMedia` in order to support the new usage.
In the future, if we want to know something like "the percentage of media element is being used for MSE/EME?", then this scalar can be the base and used to calculate the answser.
Differential Revision: https://phabricator.services.mozilla.com/D83225
