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
--HG--
extra : rebase_source : 4214c68b4c95df5c33bf1a68c9ffb84ee4c4d5aa
These are no longer needed as we have the data we were looking for.
MozReview-Commit-ID: 3WlPng3mAwt
--HG--
extra : rebase_source : 73a390f85f5c0894d53a5e8ee10b19278af58282
extra : amend_source : 6a2b9ff4191715d0ac6e43f92af1e64c59123ac6
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
--HG--
extra : rebase_source : 190e63b5df53c85f7282b5c2144ae7e7830d7ad3
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
--HG--
extra : rebase_source : fad8159c28b587572a4191f7cbde1e97e166639c
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.
--HG--
extra : rebase_source : 8be5570265adda22775f6bf7528e39dde855429f
This is because it does ensure both, and some of the callers care about
size and some care about position.
MozReview-Commit-ID: 3e8II6Lf72X
--HG--
extra : transplant_source : %EE%5E%87%1D%AA%EB%B9%22%D9%D6%D2%9D6U%C4%2A%CA%A1r%E9
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
--HG--
extra : transplant_source : J%05%F1%20M%40%88Wz%F5s_%FB%0D%0C%D6%F2%103%9B
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
--HG--
extra : rebase_source : 953eed775637a19c6d5d323ab1549f6ed5f7ff31
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
--HG--
extra : rebase_source : 416113dd2282a979ea26c4694878c2f2db578274
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
--HG--
extra : rebase_source : b5f8855b17664bb1cc2b485f1d85120c0939931f
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
--HG--
extra : rebase_source : 7b4214f1f552ba75da94e4bb1795178983af20f7
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
--HG--
extra : rebase_source : c2ab932cc3134531e5c49581c5e63b4aabef6ca4
This code now lives in TimeoutManager. Note that this is a transition
state, the Timeout list management code also needs to be refactored out
later.
In order to simplify the lifetime management of the new class, its
lifetime is equal to the lifetime of its containing nsGlobalWindow. In
a few places where we need to dispatch runnables to do asynchronous work
on this object, we hold the containing window alive to guarantee safety.
This patch also removes a bit of dead code that was left over from the
code removed in bug 1281793. See:
https://hg.mozilla.org/mozilla-central/rev/0ac748f4d677#l1.63
Blake Kaplan
Kestrel
Ryan VanderMeulen
Nicholas Nethercote
Andrea Marchesini
Alastor Wu
Bevis Tseng
Olli Pettay
Bill McCloskey
Ryan Hunt
Michael Layzell
Carsten "Tomcat" Book
Andreas Farre
L. David Baron
Iris Hsiao
Ben Kelly
Ehsan Akhgari
Phil Ringnalda
Kate McKinley
Boris Zbarsky