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>
This should be the last code backout for this. merging this branch
should get us back to the way we were (+ additional code changes for
later changes) as fasr as the unused unboxed code is concerned.
This stub is added because websites insist on considering this
very hardware-dependent and O.S.-variable low-level font-control
as a "critical feature" which it isn't as there is 0 guarantee
that font variation settings are supported or honored by any
operating system used by the client.
On top this is a WD status feature that sites shouldn't be using, and
the feature itself is strongly discouraged for use in favor of standard
CSS font manipulation keywords like `font-weight`.
This gets rid of platform-dependent hard-coded defaults, but keeps
build-time blocking if there is no GL provider (in which case layers
acceleration almost certainly won't work because it needs a GL
compositor and would likely crash without)
New prefs are
- layers.acceleration.enabled to enable HWA
- layers.acceleration.force to force it enabled (requires .enabled to be
set as well)
This is the platform part of this issue. The rest will be front-end work
(Preference UI integration and pref migration)
The indicated BZ bug was resolved in Gecko 50, and could have already
been enabled before (since it returns a promise as-required).
With the rest of promise-based media implemented it makes no sense to
keep this disabled on production.
Considering the one exception this was still enabled for on all versions
of Firefox since 45 until our fork point is no longer applicable.
This resolves#1353
This prevents cross-file access from files loaded into the browser from
the local file system, further restricting the origin policy of file:
URIs.
Added a pref to control this behavior for local file access if required
for certain applications, since this change might break using the
browser to run applications on the local file system that require
access to local files.
Still allow this to be bypassed with a pref for those really rare corner
cases where images are loaded cross-origin by design and the session
hasn't been/can't be authenticated ahead of time.
