It's possible to set `animation-name` to any of the keyword of other
properties, and this may cause ambiguity when serializing `animation`
shorthand (because we may reuse this result as an input of another
`animation` shorthand to get the same result).
So we still have to serialize these properties even if they are initial
values if `animation-name` matches them.
e.g.
Set `animation` to `normal normal`. Its serialization should be
`normal normal`, instead `normal`, because using `normal` as an input of
another `animation` shorthand makes its `animation-name` be `none`.
(Note: we parse `animation-direction` first.)
Differential Revision: https://phabricator.services.mozilla.com/D204995
We still have some ambiguous issue when `animation-name` is the same as
other keywords. We will fix it in the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D204692
On platforms where the RDD process is not enabled (Android, Solaris,
NetBSD, DragonflyBSD, iOS), video decoding is rejected because the
content PDMs are not enabled when media.allow-audio-non-utility is
false (which it is), except on Android because the
media.allow-audio-non-utility check is ifdef'ed out currently.
Instead of relying on ifdefs, rely on whether the RDD process is
enabled.
Differential Revision: https://phabricator.services.mozilla.com/D205282
The `ToTextTrackKindStr` can be replaced by `GetEnumString` since
`GetEnumString` is able to access the enum mapping strings of the
`TextTrackKind` generated by the dom binding in
`EnumStrings<TextTrackKind>::Values`
Differential Revision: https://phabricator.services.mozilla.com/D205236
The `ToStateStr` can be replaced by `GetEnumString` since
`GetEnumString` is able to access the enum mapping strings of the
`TextTrackMode` generated by the dom binding in
`EnumStrings<TextTrackMode>::Values`
Differential Revision: https://phabricator.services.mozilla.com/D205235
The `FormatToString` can be replaced by `GetEnumString` since
`GetEnumString` is able to access the enum mapping strings of the
`AudioSampleFormat` generated by the dom binding in
`EnumStrings<AudioSampleFormat>::Values`
Differential Revision: https://phabricator.services.mozilla.com/D205159
The `ToMediaSessionActionStr` can be replaced by `GetEnumString` since
`GetEnumString` is able to access the enum mapping strings of the
`MediaSessionAction` generated by the dom binding in
`EnumStrings<MediaSessionAction>::Values`
Differential Revision: https://phabricator.services.mozilla.com/D205007
The `ToMediaControlKeyStr` can be replaced by `GetEnumString` since
`GetEnumString` is able to access the enum mapping strings of the
`MediaControlKey` generated by the dom binding in
`EnumStrings<MediaControlKey>::Values`
Differential Revision: https://phabricator.services.mozilla.com/D205006
The `ToMediaKeyStatusStr` can be replaced by `GetEnumString` since
`GetEnumString` is able to access the enum mapping strings of the
`MediaKeyStatus` generated by the dom binding in
`EnumStrings<MediaKeyStatus>::Values`
Differential Revision: https://phabricator.services.mozilla.com/D204963
As noted in Bug 1556568, firstPaint records when we complete the first
render that the OS tells us to do (in nsViewManager::Refresh). This
sometimes can happen much later than we would like, skewing results. It
also is sensitive to whether or not the call to FlushRendering is sync
or async, since it fires as soon as the call is complete. For these
reasons, we'd like ts_paint to measure something more consistent, which
this patch accomplishes by changing the measurement to use firstPaint2.
firstPaint2 records in nsView::DidCompositeWindow, which measures that
the pixels have been put on the screen, no matter who asked us to do it.
This solves both problems and is the superior measure.
Because this most always measure ts_paint at a later time than current
code, this will get flagged as a performance regression. We need to
instead treat it as a measurement recalibration.
Differential Revision: https://phabricator.services.mozilla.com/D204825
