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.
As of [da0c073a7] we no longer need this workaround because the issue is avoided
with proper sleep/wake logic restored.
This reverts commit 2fa993b563.
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.
This is just a clean port of 1322191 and follow-up 1325970. It really seems to add create a new way to access existing code relating to block formatting and floating elements rather than implementing new functionality, and it is mercifully straightforwards.
Unless a user is debugging media errors, this detail is unnecessary to report
and could include sensitive data which could be abused by third-party
requesters. This aligns it with the standard success/error paradigms in normal
browsing situations.
This is not very "clean," and is mostly done in the same sloppy way as Emilio did it because that's basically the only way you can do it. Note well that this does NOT actually turn off everything I've done in a clean fashion like ifdefs would. For instance, the Explicitly Enabled flag is still present, but is now always false because the only condition that can set it true is behind the pref and therefore inert when this pref is off. Also, because the arguments of SetDisabled have changed, my modifications to SetMozDisabled must be present regardless of whether the pref is on or off. What I have done is turn off the actual reflection of the disabled attribute in Disabled and SetDisabled, as well as in AfterSetAttr.
However, turning the pref off seems to restore more or less our old behavior, though there may be subtle differences unlike with an ifdef since this is, unfortunately, not an exact science and I can only turn off changes that happen within individual functions and not changes in how functions interact with each other.
This is apparently used for fallback selection and if available it is "assumed"
Shadow DOM is also available, while this is a utility function.
Webcompat is a nightmare sometimes.
These should all be spec-compliant and were (for release-trickling of features)
arbitrarily disabled by Mozilla at our fork point. There's no real reason to
keep them disabled since they are used in the wild.
This removes the (default disabled) node.rootNode readonly attribute
and replaces it with a node.getRootNode() function per WhatWG
spec discussion.
Based on work by John Dai <jdai@mozilla.com>
Moonchild
athenian200
Matt A. Tobin
Andy
Lootyhoof
wolfbeast