Bug 1648506 disabled tests that failed on py2 on mac. Some now pass
properly, presumably from more recent changes to
build/moz.configure/init.configure.
Differential Revision: https://phabricator.services.mozilla.com/D84776
Bug 1648506 disabled tests that failed on py2 on mac. They now pass
properly, presumably from more recent changes to
build/moz.configure/init.configure.
Differential Revision: https://phabricator.services.mozilla.com/D84776
Add two new test cases for inaudible media being used in fullscreen/PIP mode.
In addition, after applying D84115, we fix the issue of incorrectly controlling media which doesn't be started yet and is not in the fullscreen. So modify the current test case.
Differential Revision: https://phabricator.services.mozilla.com/D84369
When a media enters PIP mode, we should consider it as an important one which user might want to control. Therefore, start the listener in order to notify the media has been started, then we would update the PIP state [1] which would activate the controller.
As the PIP state changes can happen after `Stop()` is called, so in this patch, we would remove the start check and reset `mControlAgent` in `Stop()` in order to update PIP state after the listener stops. Eg. Reset the PIP video's src, then cancel the PIP.
[1] https://searchfox.org/mozilla-central/rev/9b282b34b5aa0f836beb735656c55efb2cc4c617/dom/html/HTMLMediaElement.cpp#7902
Differential Revision: https://phabricator.services.mozilla.com/D84119
In D73335, we remove those check which causes a regression where inaudible media is also able to be controlled by media control keys.
In order not to control those inaudible media, we should add the check back. If the media is inaudible, then we should not start the listener that would connect media element to the media control.
In addition, I also found that starting the listener for inaudible media would make the media controller's playback state incorrect, because the playback state is calculated by all controlled media. If an inaudible media is playing, the playback state should not consider that media.
Differential Revision: https://phabricator.services.mozilla.com/D84115
It seems no much benefit to create `MediaControlKeyListener` lazily, we should create it in the start and destroy it in the end so that we don't need to check if `mMediaControlKeyListener` exists or not when we want to check if the listener starts.
Differential Revision: https://phabricator.services.mozilla.com/D84116
`NotifyMediaControlPlaybackStateChanged()` would be called when `mPaused` changes, but it would only take effect after the listener starts. If the media changes its `mPaused` before we starts listener, then we have to manully update `NotifyMediaControlPlaybackStateChanged()`.
However, I think wrapping this detail into `Start()` itself would be clearer.
Differential Revision: https://phabricator.services.mozilla.com/D84649
The reason of checking those conditions before calling `StartListeningMediaControlKeyIfNeeded()` is because we was only starting the listener after media starts, which has been modified in D79234. Now we would start the listener before media starts, so we can remove that check.
Differential Revision: https://phabricator.services.mozilla.com/D84114
`nsIFrame::ComputeISizeValue` clamps the result to non-negative before
returning it, so the assertion doesn't need to be a hard assertion.
Differential Revision: https://phabricator.services.mozilla.com/D84745
The hang duration numbers were bogus. It seems that the code in
XPCJSContext::InterruptCallback establishes the duration by continuously
comparing 'now' with the last timestamp in mSlowScriptCheckpoint - but it
stops writing to the latter after the second time the interrupt callback
fires. So if the slow script runtime limit is N, the timer fires every N/2
seconds, but we increment the duration by N the third time it fires, 1.5N the
fourth time, 2N the fifth time, etc.
This patch fixes the issue by always resetting the timestamp against which we
compare when establishing the duration and incrementing mSlowScriptActualWait.
Differential Revision: https://phabricator.services.mozilla.com/D84660
The NoValidContent type was added to detect cases where we needed to apply
default width the viewport. That approach is no longer needed, and this
enum can be removed, as well as the code that sets and checks that enum.
Differential Revision: https://phabricator.services.mozilla.com/D84447
the problem was that paths that determined visibility were not switching it off
on the primitive instance. Now it's moved one level higher.
Differential Revision: https://phabricator.services.mozilla.com/D84762
This keeps us from accumulating frame buffers without bound.
Previously I was seeing as many 56 frame buffers in this list
during a tab cycling stress test.
Differential Revision: https://phabricator.services.mozilla.com/D84760
It could go into its own test suite, but it 1) depends on `mozbuild` code, so the `mozbuild` suite as well as this new suite would be running on any push that touches `mozbuild` code anyway, and 2) this is code that runs during the build, so it's not out of place.
Differential Revision: https://phabricator.services.mozilla.com/D84547