risen is the past participle of rise; raised is the past participle of
raise, which is what is done to exceptions.
See:
https://en.wiktionary.org/wiki/rise#Verbhttps://en.wiktionary.org/wiki/raise#Verb (definition 2, though not sure
if the use for exceptions is from 2.3 or 2.5)
(I wonder if mExceptionRaised would be simpler, though.)
MozReview-Commit-ID: 8Ynup8aDcLT
This patch tells all callers to use the existing behavior, so it is
intended not to change behavior. Callers that will be modified in later
patches are marked with "FIXME" comments that will be removed in those
later patches (patches 3 and 4).
MozReview-Commit-ID: FaLryfxaeHv
The test case here does not check whether requesting restyles for empty
properties are skipped or not. It just checks that whether restyles happen or
not because there is no way to check each request for restyles yet.
MozReview-Commit-ID: I5XMYfCTYU8
--HG--
extra : rebase_source : 893aaaf2c47e05f37bce9913df4f14e3021f215a
We've observed some crashes derefing the callback pointer, which may be
occuring due to shutdown happening before init has setup the callback pointer.
MozReview-Commit-ID: JsOqfjejMVI
--HG--
extra : rebase_source : e175dd8556ad50316bc16232782e593eea3e2ec8
GeckoMediaPluginService::mAbstractThread was not reset as expected from
ShutdownGMPThread, meaning it would retain a reference to the GMP thread, and
it would allow dispatch attempts to the GMP thread after shutdown.
Also mAbstractThread was not protected by a mutex (as mGMPThread was), which is
definitely needed now that it can be reset at shutdown time.
As its prefix implies, GetAbstractThread could return a nullptr, so it should
be checked before every use.
Note that this GetAbstractThread call (and its check) has been moved closer to
the start of functions using it, to avoid unnecessary and potentially invariant-
breaking partial work to take place when we can know in advance that it won't
fully succeed because the GMP thread is not available.
MozReview-Commit-ID: B1drOeM65hr
--HG--
extra : rebase_source : 1d389c663e26a25035bf2aa22b2cca478ef954fe
FFmpeg's AVFrame pkt_dts doesn't contain the dts of the frame used to decode the frame; but of the frame "that triggered returning this frame.". The last frame was returned when draining which is done by feeding the decoder with dummy frames ; all having a dts of 0.
Additionally, rename DurationMap argument name from aDts to aKey.
MozReview-Commit-ID: GWYT3sEJVQs
data promise is only resolved once the decoder has been drained. It was possible for a promise to never be resolved if skipping to the next key frame failed.
MozReview-Commit-ID: GimbQTImH9e
Access to some members is not thread-safe; but the typical use of those informations is when a mochitest has timed out, and by that time the MFR will have been idled for over 5 minutes.
MozReview-Commit-ID: 21BxrSZXVVJ
If the Skip To Next Keyframe logic was activated, the next frame demuxed would have been passed the internal seek target, causing it to be unnecessarily dropped.
MozReview-Commit-ID: DExwMPLXlZu
Some decoders (WMF) keep some internal counters on how many frames have been output and use this to calculate the time of the decoded audio frame. As such, when internally seeking, the next frame decoded would have always been past the seek target.
MozReview-Commit-ID: puzs6ecqbD
On Windows, it is possible for the WMF decoder to consume more than the amount of frames available before outputting the first frame. So just to produce the loadeddata event, we may have in fact already reached the end of the content. To guarantee that the "playing" event is fired, we must add more data than what was originally there.
MozReview-Commit-ID: 12eQnchNGLB
During shutdown, mozilla::services::GetObserverServie will return nullptr. So we should check it. Add another nullptr check
MozReview-Commit-ID: 9xBbltRatJF
--HG--
extra : rebase_source : a859de09f30eeba344c317aec4cf4ed2cce8da2b
extra : histedit_source : 325aba902eff367d046807e9be3a73ad3100ee67
This follows a spec change <https://github.com/whatwg/html/issues/293>,
which AFAIK no other browser has implemented, so it has some regression
potential.
The web-platform tests changed are out-of-date and match the old spec,
so I'm changing them here to match the new spec.
There were two places run gAnimationsTests in
test_animation_performance_warning.html.
MozReview-Commit-ID: zrD5eMiDsy
--HG--
extra : rebase_source : 250f826daed4440725c0a28fdb1fcd84fd299402
This function will be used for the warning of small content as well.
MozReview-Commit-ID: EiUF9CgWGDA
--HG--
extra : rebase_source : 3b6daa713d889f5c51507d4c1f6fd6c51f1e7fb9
In bug 1264497 we discovered that Netflix was broken because we'd made a change
to not send the Adobe GMP the device bound nodeId, which it stored in GMP
storage. When the GMP was comparing the nodeId it had stored against what it was
passed (nothing) the comparison was failing. Users could have worked around this
problem by clearing their GMP storage, whereupon the Adobe GMP will have stored
"nothing" as its nodeId.
When bug 1264497 was fixed, users who'd cleared their storage will see Netflix
fail again, as their stored nodeId of "nothing" will again not match what we
pass in. So to fix Netflix for these users, we need to clear GMP storage.
This is another instance of a more general problem that we have occasionally
encountered, namely that sometimes GMP storage becomes incompatible, and we
need to clear it. Having a general mechanism that we can use to clear storage
remotely will be helpful, so this patch adds one, and triggers it to fire.
This mechanism is pref controlled, so that we can issue a hotfix if necessary
to clear GMP storage.
MozReview-Commit-ID: GzSyBj0P2JG
--HG--
extra : rebase_source : b854860ee533b0742a664c862278ce54c9052596