Capturing |this| only if |self| needs to appear more than twice in a lambda.
MozReview-Commit-ID: 38iYDznjgBH
--HG--
extra : rebase_source : 9471fd4519c5c5be6e6e10eb11db8eeb041327d1
Before this patch, we had been checking each scrollable ancestor is scrolled
out of its scrollable ancestor. So if the target animating frame is at the
bottom of its scrollable parent and if half of the scrollable parent is
scrolled out of its ancestor, the animating frame was considered as 'in-view'.
MozReview-Commit-ID: BDueuF3cT4I
--HG--
extra : rebase_source : de1dead6e67a44691887c8364be23734c3b1adef
When we receive animations on the compositor, we assert that either they're not
playing, or they have a resolved start and origin time.
However, on the main thread we determine if an animation is playing by checking
if it has a timeline, if it's in the correct state, and if it has a non-zero
playback rate.
The problem with this check is that if an animation has a timeline but it is
inactive, that is, its current time is null, we will not be able to get
a resolved origin time -- yet we will still report that is is playing.
This patch fixes this mismatch by treating animations with an inactive timeline
as "not playing".
The IsPlaying() method is used a number of call sites but it appears that they
all would expect an animation with an inactive timeline to be considered "not
playing". Furthermore, this makes IsPlaying() consistent with the check we do
for an active timeline in other functions such as Animation::Tick(),
TriggerNow(), SilentlySetCurrentTime(), UpdateFinishedState(),
and IsPossibleOrphanedPendingAnimation().
MozReview-Commit-ID: BQOBpHHFMoD
--HG--
extra : rebase_source : e84a50a16a61d48553610cb7ea0863f09ba86c60
In some circumstances it is possible to sample a timed element in the active
state with a time that precedes is current interval.
One possible sequence of steps leading to this situation is as follows:
1. A timed element (e.g. <set>, <animate>) with a non-zero begin time is the
child of <svg> element A (its "time container") but has yet to be sampled.
2. In order to resolve its initial interval, the timed element registers a
startup milestone with its time container at time 0.
3. However, before the sample is performed where the timed element's initial
current interval is resolved, <svg> element A is detached from the document
tree.
4. The timed element is then attached to a different <svg> element B that has
a current time greater than the begin time of the timed element and less than
that of <svg> element A.
5. Since the timed element is still in its startup state it registers its
startup milestone again, this time with its new time container, i.e. <svg>
element B.
6. A tick occurs or the document has its style flushed such that a sample is
performed.
This includes running the milestone sample which causes the timed element to
resolve its initial current interval. Furthermore the subsequent regular
sample of the timed element causes it to transition into its active state
because the current time of <svg> element B is greater than the begin time of
the timed element.
7. <svg> element A is re-attached to the document.
8. When we go to run the next sample, we iterate through all time containers
associated with the document's animation controller which includes both <svg>
element A, and <svg> element B.
9. <svg> element A renders up its 0 milestone from step (2) since it has yet to
run it. It converts this to parent time, i.e. the time space of the animation
controller, which will be zero or less depending on the current time of <svg>
element A when it was re-attached.
10. Since the milestone from <svg> element A will be the earliest milestone
time, it will be used as the next milestone sample time.
11. The timed element is then sampled using this time, but first it is converted
to a time in the time space of the timed element's time container, which is
now <svg> element B.
As a result of this conversion, the sample time may end up being *before*
the beginning of the timed element's current interval. Since timed elements
never expect the time to go backwards an assertion fails when it detects
that it is active, but is being sampled before its current interval.
For this particular case, ignoring the "early" sample seems to be the most
appropriate action.
More generally, however, we can anticipate other cases similar to this where
milestones are registered that cause the sample time to temporarily go
backwards. A quick audit of nsSMILTimedElement::DoSampleAt suggests that, with
the code changes from this patch, that is probably ok.
As an alternative we could, perhaps, try to drop and re-create all milestones
when time containers are re-attached to the document tree but that would add
more complexity and would not necessarily cover other similar cases of this
situation.
I have verified that the crashtest included in this changeset fails without the
code changes also in this changeset.
MozReview-Commit-ID: KKGYRayNkpo
--HG--
extra : rebase_source : 832d4b357a2a2fe07abf9eab3a6046599aff3ef5
There are no reliable steps to make this happen but it appears to have happened
at least twice during fuzzing. As a result, it doesn't matter too much what the
behavior here is as long as we don't crash.
MozReview-Commit-ID: 4gdiBL2wngU
--HG--
extra : rebase_source : 54afce721f8b59c2ad038e0c2222f64e71a9b917
According to FFmpeg documentation, the out parameter is "set to size of parsed buffer or zero if not yet finished. " however this is only the case if no error occurred; otherwise it is left untouched.
We want the invalid content to generate a decoding error, so we set size to inputSize to ensure decoding failed later.
MozReview-Commit-ID: FZeiZUdUtLG
--HG--
extra : rebase_source : 2e81d730bacaea5bb968f704a36b403117dafcba
When server responses a field value with null, we have to ignore it, or we fail to SetRequestMethod for the http channel.
MozReview-Commit-ID: EW9NHMy22Fc
We queried 'loadingprincipal' attribute on the common call path, however
this should be queried if it's loaded by System Principal.
Also rename loadingprincipal to triggeringprincipal
The test case uses double intervals to make sure there is enough time to wait for the scroll event before continuing the testing. However, it doesn't work while the first timeout is delayed and the second one isn't. Tweaked the test case to start the second timer when the first one timeout.
MozReview-Commit-ID: gvhtIpzauE
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive. This patch splits that macro into three new ones that are harder to
mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 3e2bbec4737b696e1c86579ae54be4cb3186c100
This also brings in and convert some utilities we have in Gecko, that will ease
porting more tests.
MozReview-Commit-ID: 2yPZQO504kH
--HG--
rename : dom/media/webaudio/test/test_analyserNodeOutput.html => testing/web-platform/tests/webaudio/the-audio-api/the-analysernode-interface/test-analyser-output.html
extra : rebase_source : 0a9c9c336b1b53120010a081da131c76f103a838
