Previously, the targetNodeCb used in TooltipToggle had an inconsistent API. If
returning synchronously, "false" would prevent the tooltip from appearing.
However, if using a promise, resolving "false" would still show the tooltip.
It was needed to reject the promise in this case to prevent the tooltip from
being displayed.
This commit makes TooltipToggle always expect a consistent return value from
this callback, whether it is synchronous, or using promises.
- true -> show the tooltip on the event target
- DOM node -> show the tooltip on the provided node
- false (or falsy value) -> do not show the tooltip
MozReview-Commit-ID: 7PIPwBJxjWO
--HG--
extra : rebase_source : 279bab30f631a3a65a93b52226c6980210abf2f1
The code used to make the tooltip appear/disappear when hovering targets
has been extracted to a separate class that can be shared between the
current Tooltip.js implementation and the upcoming HTMLTooltip.
MozReview-Commit-ID: UYSjPFeMYK
--HG--
extra : rebase_source : 5dcca2d5887ffc98fec621092640073a0909c13f
During tests that open additional tabs, the main test tab controlling the test is at risk of being zombified if a memory pressure event arrives, which breaks the test and leads to the test timing out. Therefore, we now disable background tab zombifications during tests.
This means that there's a slightly increased risk of being OOM killed instead, however
- the tabs opened by the tests themselves are normally relatively short-lived anyway
- we're no worse off than if the tab containing the test harness code had been zombified.
MozReview-Commit-ID: 1Ntvn4yjWlZ
--HG--
extra : transplant_source : %E78%93%3B%0F%5DnX%BC%E6G%10%B2%B5%1B%3A%9F%CE%F9%DD
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
Marco Bonardo
Panos Astithas
J. Ryan Stinnett
Julian Descottes
James Long
Ryan VanderMeulen
Tom Tromey
Luca Greco
Jan Henning
Carsten "Tomcat" Book
JW Wang
Jean-Yves Avenard
Astley Chen
Edouard Oger
Timothy Guan-tin Chien
Jared Wein
Drew Willcoxon
Wes Kocher
Gijs Kruitbosch
Andrea Marchesini
Jacek Caban
Steve Melia
Nick Fitzgerald
Nicolas Chevobbe
Ehsan Akhgari