It seems the build has been broken on desktop platforms. This is a
preliminary fix to getting this build on the bots.
This is mainly missing includes, but `package-prefs.json` is no longer
processed because that was only used for the UWP port (now removed.
Pinch zoom was broken because pinch zoom events were triggered at -1, -1
in the compositor. This change:
1. Differentiates between magnify and scroll events in the compositor to
remove the question of where to trigger them.
2. Converts winit TouchpadMagnify events into pinch zoom events so that
this works properly on MacOS.
These are gated by the same layout.css.font-tech.enabled pref as the
closely-related `tech()` function for the @font-face src descriptor;
once the spec questions are settled, we should enable them all together.
Differential Revision: https://phabricator.services.mozilla.com/D155359
There are a couple of current issues/discussions that may lead to a change in the set of supported keywords, so we may want to hold back a little on actually shipping this.
- In https://github.com/w3c/IFT/pull/113, the WebFonts WG proposes several new incremental-* keywords (and maybe implies dropping the currently-defined incremental?)
- In https://github.com/w3c/csswg-drafts/issues/7633, I just proposed renaming the feature-* keywords to features-* (plural) for better readability; I'd like to see a decision on that before we ship this to release.
Differential Revision: https://phabricator.services.mozilla.com/D155458
Fix some tests to:
* Not assume `double` precision.
* Account for recent working group resolution with regards to NaN: https://github.com/w3c/csswg-drafts/issues/7067#issuecomment-1111211295
Not sure I caught all, but normalizing to 0 was already our existing
behavior. This feature needs more work before it can be enabled more
generally, so make it nightly-only, for now.
Also, it's unclear per spec what the serialization for infinity*1s or so
should be. Right now we serialize to <very-big-number>s, which seems
reasonable, but some tests (but not others!) expect different behavior.
I left those untouched for now.
Differential Revision: https://phabricator.services.mozilla.com/D154883
We now have test coverage, so let's do this.
The remaining failures are just about infinity/nan, which is a
completely different feature.
Differential Revision: https://phabricator.services.mozilla.com/D154831
Now that the style system has keywords for this, we don't need to define them in gfx
but can just use the enum directly. (No functional change, just code simplification.)
Depends on D154237
Differential Revision: https://phabricator.services.mozilla.com/D154238
This aligns with CSS Fonts 4 (rather than Fonts 3) and with behavior in other browsers;
I don't expect any significant breakage, given that specifying multiple format strings
was never supported in other engines AFAIK, and never served any useful purpose.
Depends on D154234
Differential Revision: https://phabricator.services.mozilla.com/D154235
We have unshipped these since forever, no point in keeping the pref
around. Move the relevant tests to chrome ref/mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D154152
This matches what Linux and macOS do, and that allows the fix for bug 1782623
to work on Windows for unstyled selects.
This also simplifies the CSS (though it adds a new system color which is a bit
more annoying). I filed https://github.com/w3c/csswg-drafts/issues/7561 to
propose adding a more generic way to do this in the future (not just for
Firefox).
Differential Revision: https://phabricator.services.mozilla.com/D153549
When something switches to display: none, right now we rely on
StopAnimationsForElementsWithoutFrames(), which posts a restyle and the
previous ProcessPendingRestyles call was papering over it.
For other elements in the display none subtree it doesn't matter,
because we don't keep their styles around, but for the display: none
element themselves we do need to update transitions on time.
We could, possibly more generally, remove
StopAnimationsForElementsWithoutFrames() altogether and cancel
animations when we clear style data, perhaps... But that's probably
worth a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D151600
Even we don't have internal aliases right now (and that seems a bit
silly) we do have pref-gated aliases. An alias ID passed to IsEnabled
with the wrong EnabledState would misbehave, assert, and crash.
Though we don't have such callers in the tree because InspectorUtils
passes only arguments that make us not look at the flags, it seems more
reliable this way.
Differential Revision: https://phabricator.services.mozilla.com/D151594
So we can specify the keyframe-specific composite operation. However,
these is a spec issue about the default composite for CSS Animations:
https://github.com/w3c/csswg-drafts/issues/7476.
I choose to use auto as the default composite for missing keyframes to match
the definition in web-animations-1 because I think this makes more sense:
> If the keyframe-specific composite operation for a keyframe is not set, the
> composite operation specified for the keyframe effect as a whole is used for
> values specified in that keyframe.
Differential Revision: https://phabricator.services.mozilla.com/D150808
This patch introduces animation-composition longhand but we don't
accept it in @keyframe rule for now. I will support this for @keyframe
in the patch series.
Besides, the shorthand of animation doesn't include animation-composition.
The spec issue is: https://github.com/w3c/csswg-drafts/issues/6946.
We could fix the shorthand once this spec issue gets updated.
Differential Revision: https://phabricator.services.mozilla.com/D150299
