The removal of this preference was botched, all other surrounding plumbing changes appear to be working okay. The ability to use prefs to control this stylesheet might be useful in the future, so perhaps this is one of those "if it ain't broke, don't fix it" bugs where leaving well enough alone in the first place would have been the best choice.
This PR passes all current tests for this feature, and implements the "prefers-color-scheme" media query as an enumerated keyword that is controlled by an integer preference.
Currently, the possible options are 0 to see a website's fallback code and essentially behave like this isn't implemented (our current behavior), 1 to express a preference for a light theme (the default for spec reasons), and 2 to express a preference for a dark theme. Over time, this list may expand to include other preferences like a preference for a sepia theme or something, and this leaves us prepared for that future.
- Enabled SVG transform-box property. I've tested this extensively including the
bug that prevented Mozilla from shipping until 55 which does not seem to apply
to us (most likely a stylo issue). Should be good to go.
- Moved the getRootNode pref to a better place (no change)
- Enabled inputmode property for forms. This is n/a for physical keyboards but
should improve the experience for soft keyboards that can pop up various forms
of input (e.g. numeric) depending on the mode indicated. According to BZ this is
feature complete at our level but was problematic for Android which we don't
have support for anyway.
- Restricted crashing on insecure input of text to debug only.
- Enabled shutting down the async OSFile worker if not used for 30 seconds to
be more conscientious about resource use.
- Enabled blocking of autoplay of media in the background by default, since it
is a saner default to have for the OOBE and is commonly a desired setting by
users (see forum).
- Disabled the storage manager API by default. This fine-grained control over
stored website data is already handled by various extensions and we don't have
the front-end support for it. Assuming this was necessary for Mozilla due to
limited access of WebExtensions to this kind of data.
This enables the DOM Animations API core functions with the exception of those
parts that are either unimplemented or not ready for use, which have been
preffed off in this issue's previous parts.
Also tag #1319 for enabling a previous RELEASE_OR_BETA shielded API.
This is probably the last thing we will ship (if ever) since it needs the most
spec and implementation work for arbitrary use that is pretty far into a corner.
This feature should not be shipped until the various definitions of addition for
each additive property are properly specified and then implemented accordingly.
Unlike other patches in this series, compositing is not frequently used
internally so there is no need to enable this by default for chrome callers.
This preference controls whether authors are allowed to specify animations
without a 0% or 100% keyframe.
We intend to ship this but it isn't implemented yet (needs a follow-up) but this
preference acts as a safeguard in case we discover we need to disable it once
it's implemented.
There don't seem to be any drawbacks to this; tested for the past month disabled
and there have been no issues with any sites visited. Adoption seems very low.
