This was needed before as the base to nsGlobalWindow, but now that
nsGlobalWindow doesn't exist, and we only have specific versions, we no longer
need this type.
MozReview-Commit-ID: 6IJmJtnSkMr
Since now we move the block/resume logic to front-end side, we can remove
the changing from bug1319771 and other related bugs which are used to ensure the
pinned tab should be blocked successfully after session restore.
MozReview-Commit-ID: Ixe7tOvCEhv
Since now we move the block/resume logic to front-end side, we can remove
the changing from bug1319771 and other related bugs which are used to ensure the
pinned tab should be blocked successfully after session restore.
MozReview-Commit-ID: Ixe7tOvCEhv
This commit adds a telemetry probe to determine the percentage of pages
that ever have a 'mousemove' event listener added to the DOM. This is for
determining how often APZ key scrolling could handle interleaved mousemove
events.
A flag is added to nsPIDOMWindow to track whether a qualifying event
listener was ever added to the DOM for this window, and is updated by
EventListenerManager. There are several other similar flags to this.
The probe is reported in nsGlobalWindow::FreeInnerObjects() so that it
can be compared exactly with the non-passive keyboard listener APZ probe.
MozReview-Commit-ID: DqqCfrdRCGp
Clear the throttle tracking timer in ClearAllTimeouts. Also clear it
in Suspend, and if mThrottleTrackingTimeouts isn't set restart the
timer if the document hasn't loaded.
This reduces the amount of flushing we do when these APIs are called on
the root document, but increases the amount of flushing we do (probably
fixing existing bugs) when these APIs are called in a document at depth
three or more (if you consider the root depth one).
I considered the idea of adding a EnsurePositionUpToDate alias, but it
seems that some of the existing users of EnsureSizeUpToDate actually
care about position (e.g.,
nsLayoutUtils::GetDeviceContextForScreenInfo), so I just added a comment
instead.
MozReview-Commit-ID: B3L5DDQ5krc
We should let window decide whether resume the media component, not document.
Because we might have media component which is not in DOM tree, but we still
want to play it.
Window should be resumed when all following conditions are true,
(1) the tab is in the foreground
(2) there is any alive media component (MediaElement/WebAudio/PlugIn...)
(3) the window is blocked (nsISuspendedTypes::SUSPENDED_BLOCK)
MozReview-Commit-ID: JXw5MA4FCxF
We should let window decide whether resume the media component, not document.
Because we might have media component which is not in DOM tree, but we still
want to play it.
Window should be resumed when all following conditions are true,
(1) the tab is in the foreground
(2) there is any alive media component (MediaElement/WebAudio/PlugIn...)
(3) the window is blocked (nsISuspendedTypes::SUSPENDED_BLOCK)
MozReview-Commit-ID: JXw5MA4FCxF
In websites such as Facebook Live, timeout chains are used to drive the
playback of a video or something similar in JavaScript. Throttling the
minimum timeout values a tab playing a video from such websites in the
background could make the timeout based scheduling of video playback to
not work correctly, and cause audio buffer under-runs that are audible.
In order to address this, other major browsers don't throttle timeouts
in tabs that are playing audio. This brings us to parity to other
browsers (even though we already do this for websites that use Web Audio
since we've had similar bug reports using the Web Audio API.)
The current audio agent setup that drives the tab audio notification
icons is currently tracking whether a Window is playing audio. We use
this setup to decide whether to throttle timeouts when a window goes
into background.
In present design, the tab would hide the unblocking icon when receives
the audio-playback event, but it means we can't hide the icon if the media isn't
audible.
For example, we won't show the unblocking icon for audio with audio track, but
we show the icon for audio with silent audio track which can only be detected
after starting decoding.
In this case, we can't receive the audio-playback after resuming that media.
Therefore, we should dispatch the different event to notify tab UI that the
tab has already been resumed.
MozReview-Commit-ID: 3xCWQU7nVCl
In present design, the tab would hide the unblocking icon when receives
the audio-playback event, but it means we can't hide the icon if the media isn't
audible.
For example, we won't show the unblocking icon for audio with audio track, but
we show the icon for audio with silent audio track which can only be detected
after starting decoding.
In this case, we can't receive the audio-playback after resuming that media.
Therefore, we should dispatch the different event to notify tab UI that the
tab has already been resumed.
MozReview-Commit-ID: 3xCWQU7nVCl
In previous patch, we modify the behavior of nsDocument, now it would only resume
window when document has active media components.
However, it causes another issue. If the tab really goes to foreground, but
there is no active media component, the tab would still be blocked and it won't
be resumed anymore.
Therefore, we need to resume it by ourself if the tab is on the foreground but
doesn't be resumed yet.
MozReview-Commit-ID: EdnQ7sRkSJK
