When the pending animation having no target element sets a new effect having
a target element associated with a document, PendingAnimationTracker has to
start tracking the animation regardless of mPendingReadyTime.
MozReview-Commit-ID: DxmbXtLhjCT
--HG--
extra : rebase_source : 46c9a51e7d3b971a0c0ffcf94b579d22450028f5
The function will be used in the case of KeyframeEffect::SetTarget too.
MozReview-Commit-ID: G6ipjxaIJsW
--HG--
extra : rebase_source : 609fa17d698612df21d9cac469e6997582dcca69
It might be possible that we can check whether an animation is being tracked
by the pending animation tracker without this function to count layout flush
since we force to flush layout if there is any pending animations [1]. But
it will probably result complicated test cases. So to make test cases simple,
we introduce a new function which just checking whether a given animation is
being tracked by the pending animation tracker.
[1] https://hg.mozilla.org/mozilla-central/file/3d20b0701781/layout/base/nsRefreshDriver.cpp#l1957
MozReview-Commit-ID: 4lWuOYCucaD
--HG--
extra : rebase_source : a42866d1b9828820c112ac8f756372648da8763f
In bug 1404042, we determined that video playback of software based surface was very slow and power hungry when using the intel GPU, but was working okay when using the dGPU (either AMD or nVidia)
So always return false in IsVP9DecodeFast when the current GPU is an Intel, as well as return a benchmark score of 0
Force a new run of the benchmarking by bumping the version number.
Differential Revision: https://phabricator.services.mozilla.com/D2075
--HG--
extra : moz-landing-system : lando
In bug 1404042, we determined that video playback of software based surface was very slow and power hungry when using the intel GPU, but was working okay when using the dGPU (either AMD or nVidia)
So always return false in IsVP9DecodeFast when the current GPU is an Intel, as well as return a benchmark score of 0
Force a new run of the benchmarking by bumping the version number.
Differential Revision: https://phabricator.services.mozilla.com/D2075
--HG--
extra : moz-landing-system : lando
nsGlobalWindowInner::GetExtantDoc() can potentially return null, and
we're not null checking its return value in
MediaManaager::IsActivelyCapturingOrHasAPermission() which I think is the
cause of this crash.
So instead of getting the principal from the window's extant doc, we can
get the principal directly from the nsGlobalWindowInner.
MozReview-Commit-ID: BUwiJGLss2a
--HG--
extra : rebase_source : 5135a2ef524044c44046705f4a7c7516f01f6b34
Scrolling is not permitted along the axis whose overflow style is hidden. In
the mochitest test_wheel_default_action, tests which checked if overflow hidden
pages were scrollable failed after the changes in the Part 1 patch were
submitted to try. The tests failed as overflow hidden pages were scrollable.
After investigating the sequence of events, we realized that the
overflow-x:hidden property was taking effect on the compositor thread after the
scroll-wheel event was received on the compositor thread. Therefore, scrolling
took place even before the scrollable rect was sized appropriately and
scrolling beyond the layout viewport size was possible. To solve this, we wait
for all repaints to occur before the test sends a scroll-wheel event. Waiting
for all repaints guarantees that the overflow-x:hidden property will be set
before a scroll-wheel event is received.
MozReview-Commit-ID: 2hc3MTyKhnS
--HG--
extra : rebase_source : 3e84905826a1b7430a245734eaadbda2aadf0e27
When setting contenteditable to false, editing session destroys HTMLEditor.
Destroying HTMLEditor means that selection visibility is reset by
FinalizeSelection.
So after calling TearDownEditorOnWindow on nsHTMLDocument, we should initialize
selection visibility if current focus is text control that has editor.
MozReview-Commit-ID: 4V8kZtOtKO3
--HG--
extra : rebase_source : 9d90c12b3c93e4dfd95095ce29a26e5fdd83f952
Before this change, the test in this commit fails. The received events order
is;
1) cancel
2) transitioncancel
3) transitionstart
4) finish
MozReview-Commit-ID: 8liTFXime6e
--HG--
extra : rebase_source : 3c68ef330b1f263afa2fad9670a30b351b8dbf28
Changing to Stylo for animation of color with currentColor. Stylo uses
a different distance metric for numeric colors to currentColor. The
result is that a different pacing is used in the fill case.
MozReview-Commit-ID: 5x8c3IF5owV
--HG--
extra : rebase_source : 422dfa69644052a4c9cbfb2355a105c8e5c2b50c
There doesn't appear to be any need to separate these anymore.
MozReview-Commit-ID: GHR259JJHJV
--HG--
extra : rebase_source : e9b15c820df97570c3f6e978a7f0c224e33f0468
This is no longer needed since in bug 1456394 we merged the two types of
KeyframeEffects into one.
MozReview-Commit-ID: 8IuTD9ivAGK
--HG--
extra : rebase_source : b14593b33bfa9a0233b524010b3bde3cfc078950
navigator.platform returns "Win64" in 64-bit Firefox and IE, but "Win32" in 64-bit Chrome and Edge. "Win32" appears to be the de facto platform value for Windows. This change doesn't hide the OS architecture from web content because navigator.userAgent still mentions "Win64; x64" in 64-bit Firefox, Chrome, Edge, and IE.
MozReview-Commit-ID: CplYnGDQgTe
--HG--
extra : rebase_source : c00a1a7462ea91d44700dd0581c88c1c4cad2346
extra : source : 1976c327f251702be255a9d0769121c6bc5303a1
Fix clang-tidy warning about bool pointers:
[misc-bool-pointer-implicit-conversion] dom/quota/ActorsParent.cpp:4168:7: warning: dubious check of 'bool *' against 'nullptr', did you mean to dereference it?
MozReview-Commit-ID: C6QdeJlf71C
--HG--
extra : rebase_source : cb2e19e41bed6cc1456e89acce65747558306bcf
I guess because, in the old world, registrations were propagated everywhere we
could end up in a state with an old ServiceWorkerRegistrationInfo while our
ServiceWorkerRegistration thought that everything was up to date. I think that
what should eventually happen will be that when we eventually get our updated
Info, we'll update the state of the ServiceWorkerRegistration accordingly and
things should work themselves out.
Differential Revision: https://phabricator.services.mozilla.com/D2077
--HG--
extra : moz-landing-system : lando