This patch changes our handling of durations in the WMF video MFT manager.
Prior to this patch we had some handling for if VP9 samples were returned with
zero duration. However, this patch extends this to the general case so that we
will try and estimate the duration using Gecko data in the following cases
- If Windows returns an error code when getting the duration. This can be
because the duration is unknown, but the API also specifies it can fail due to
other, unstated reasons (we handle these too).
- If Windows returns a 0 duration. This is also used to indicate an unknown
duration. We now handle this for arbitrary codecs, not just VP9.
- If Windows returns a negative duration. It's unclear if Windows will do this,
and if it does, under what cases. However, since the API returns the duration
as an signed int it's possible, so we cover this too.
In all cases above, we will use the duration we record from our last input
sample as the output sample duration.
Differential Revision: https://phabricator.services.mozilla.com/D114247
History shows that the test being modified here tries to test crashiness of
what happens from the onblur handler. That the initial focus originally happened
from the HTML parser instead of from a stable state seems unimportant for the
purpose of the test but introduced an opportunity for timing differences between
runs.
Differential Revision: https://phabricator.services.mozilla.com/D114068
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
when the setter should not throw because there are no events in the timeline
and the time is known valid.
This will allow us to make SetValue() throw when it conflicts with a
setValueCurveAtTime() curve.
Depends on D113937
Differential Revision: https://phabricator.services.mozilla.com/D113938
Add more logging to test file_fullscreen-scrollbar.html (executed by dom/html/test/test_fullscreen-api.html) so it is easier to understand failures.
Differential Revision: https://phabricator.services.mozilla.com/D114187
I have still yet to reproduce this. However, it looks like it could happen if
two documents load the same script and they both finish at the same time
and one clears the mCurrentScriptProto of the other.
Differential Revision: https://phabricator.services.mozilla.com/D113602
We increase |jumps| for steps(<integer>,jump-both), and the <integer>
could be a large number, so we have to avoid the int overflow. Now we use
CheckedInt32 for it.
Also, `aPortion * aStepFunc.mSteps` may be out of the range of int32_t,
so we clamp it first and use CheckedInt32 for currentStep, too.
The error handling is pretty simple. We don't care about the result of
this unexpected behavior, so we simply roll the value back to the
original one.
Differential Revision: https://phabricator.services.mozilla.com/D112684
This also makes it so that we will never fire SSTabRestored without first having
sent the associated SSTabRestoring event.
Differential Revision: https://phabricator.services.mozilla.com/D110335
This should help avoid message ordering issues in the next patches. To ensure
that we're not firing events too early, we now do a "full" restore even if we
don't have form or scroll data, including for about:blank URIs.
This also moves all restore state on the CanonicalBrowsingContext into a
separate `mRestoreState` struct.
Differential Revision: https://phabricator.services.mozilla.com/D110333
Warn when some of the pre-conditions fail and such, so that it's easy to
see what's going wrong without having to use a debugger.
Remove some useless null-checks (we were dealing with null arguments
anyways, and the return value is never null).
Depends on D114078
Differential Revision: https://phabricator.services.mozilla.com/D114079
The previous assumption was that mType would be updated before AfterSetAttr(), but that assumption is invalidated by bug 1347640. This patch moves the radio group addition part to the position after HandleTypeChange() is called.
Differential Revision: https://phabricator.services.mozilla.com/D114038