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
When a tab is in the background, its document visibility would become invisible even if a tab owns a video which is visible because of being used in picture in picture mode.
When a document changes its visibility, the wakelock would change its lockstate from `lock-foreground` to `lock-background`. For `video-playing` wakelock topic, we would only request a real platform lock for `lock-foreground` because we don't want to prevent screen from sleeping if the video is invisible.
Therefore, considering if video is being used in picture in picture mode, when determining the wakelock's visible state. If video is still being used in picture in picture mode, then we would treat wakelock as if it's in foreground in order to keep a screen lock.
Differential Revision: https://phabricator.services.mozilla.com/D90781
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
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
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 broke in bug 1636728 because we started setting the bit in the
cloned docshell rather than the original one.
Behavior in other browsers seems to be a bit all over the place, but for
now keeping our behavior during window.print() seems sane.
Differential Revision: https://phabricator.services.mozilla.com/D90456
By passing the content viewer to CreateStaticClone we can do this fairly
easily. I'm going to add another entry-point to the clone process and
it'd be good if we avoid repeating the SetDocument dance and so on.
Differential Revision: https://phabricator.services.mozilla.com/D90315
Not really a fan of this, but I can't think of a better alternative
really... Ideas welcome :)
The main issue is that in bug 1662975 we made window.print() not return
until the user has closed the print / print preview dialog (as it is
needed for some use cases). This matches other browsers, too.
We use an nsAutoSyncOperation here, in order not to violate the
run-to-completion invariants, which turns off micro-tasks, timers,
etc... However we'd still want promises inside mozPrintCallback to
resolve and such, which is a bit contradictory. It is really awkward to
have this behavior change based on whether we have a print callback...
Differential Revision: https://phabricator.services.mozilla.com/D89298
Not really a fan of this, but I can't think of a better alternative
really... Ideas welcome :)
The main issue is that in bug 1662975 we made window.print() not return
until the user has closed the print / print preview dialog (as it is
needed for some use cases). This matches other browsers, too.
We use an nsAutoSyncOperation here, in order not to violate the
run-to-completion invariants, which turns off micro-tasks, timers,
etc... However we'd still want promises inside mozPrintCallback to
resolve and such, which is a bit contradictory. It is really awkward to
have this behavior change based on whether we have a print callback...
Differential Revision: https://phabricator.services.mozilla.com/D89298
Before bug 1636728 this couldn't happen because print documents weren't
hosted in an <browser>. The presentation of documents that are being
printed should be managed by the print job.
We should, in fact, probably just make mDocument->IsStaticDocument() the
condition, or such.
Differential Revision: https://phabricator.services.mozilla.com/D88901
