Intent to ship: ETP strict mode shims for content-blocked resources (aka SmartBlock)
As of Firefox 87, I intend to enable ETP shims by default on desktop and Android. ETP shims are work-arounds for website breakage which is caused by blocking specific scripts in ETP strict mode and private browsing mode (see the intent to prototype for more context). Shims for the following scripts will be enabled in 87: - Ads by Google - BmAuth by 9c9media - Eluminate (coremetrics.com) - Google Analytics (and its Tag Manager and e-commerce plugins) - Google IMA3 - Google Publisher Tags - Rambler - Rich Relevance Note that shims for the Facebook SDK and Ad Safe Protected's Google IMA adapter will remain nightly-only and will not be enabled for Firefox 87, as they require further UX work ( https://bugzilla.mozilla.org/show_bug.cgi?id=1661330). Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1693386 This feature was previously discussed in this "Intent to prototype" thread: https://groups.google.com/g/mozilla.dev.platform/c/28eWGe4s5a8 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to prototype: ETP strict mode shims for content-blocked resources
Summary: ETP strict mode performs content-blocking, which can cause breakage on many sites ranging from features like Facebook's federated logins not working, to sites not being able to load at all. This currently occurs in private browsing mode, and/or if the user has enabled the option in Firefox preferences. Shims serve as stand-ins for specific blocked resources, mimicking them well enough to un-break webpages. They additionally allow users to opt into loading the original blocked resource, on a per-resource and per-TLD basis, to allow users to (for instance) log into a specific site with Facebook by just clicking on the usual login button to open the related login popup, without having to take extra actions to allow the Facebook script and refreshing the page. This way users pick and choose which resources are allowed on which sites, to minimize what is actually allowed through ETP content blocking. Shims are shipped as part of the pre-existing webcompat system/built-in addon (not hosted remotely). Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1637329 Standard: None. The same basic concept is being used by DuckDuckGo's privacy extension as well as uBlock Origin, using the name "surrogates", but without the user opt-in concept. Platform coverage: - Desktop nightly in 81, riding to release for 82. - Android TBD (but currently aiming for the same schedule). List of shims initially enabled: - Allow federated logins with Facebook and Rambler - Fix basic site breakage related to: - Ads by Google - Ad Safe Protected's Google IMA adapter - BmAuth by 9c9media - Eluminate (coremetrics.com) - Google Analytics (and its Tag Manager and e-commerce plugins) - Google IMA3 - Google Publisher Tags - Rich Relevance Preference: extensions.webcompat.enable_shims = true|false Individual shims may also be disabled, for instance: extensions.webcompat.disabled_shims.FacebookSDK = true DevTools bug: None. A message will be logged to the web console for each shim which is active on a given page, linking to their related Bugzilla bug. Other browsers: None by default to my knowledge. but as mentioned, DuckDuckGo browser's privacy extension has a similar "surrogates" feature, as does uBlock Origin. Test coverage: Mochitests are provided for test-coverage, as this is not presently a standards-track feature, and requires tests for a system/built-in addon. Security & Privacy Concerns: Users may opt into allowing otherwise-blocked resources, as desired. This will of course thwart content-blocking, so to limit the risk the user will need to opt in on a per-TLD basis, and the web API exposed by shims (to match the original scripts being shimmed) is limited to only being allow to specific resources through ETP content-blocking on a case-by-case basis, and only if they intend to allow user opt-ins in the first place. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: CSS media queries, interaction media features
Summary: Implement the CSS features [any-]pointer:{none|coarse|fine} and
[any-]hover:{none|hover} in a manner that is compatible with Blink. These
features are implemented in all other major engines including Edge, and
sites like Gmail are now using them. Our lack of support for these features
has also caused some developer friction, especially since our proprietary
-moz-touch-enabled feature seems to have flown completely under the radar.
Bug: 1035774
Link to standard: https://dev.w3.org/csswg/mediaqueries4/#mf-interaction
Platform coverage: Windows, OSX, Linux and Android (though OSX/Cocoa seems
to have no APIs to expose this information, so we will fall back to the
same "user only has a mouse" values that Blink and WebKit use on OSX).
Estimated or target release: Firefox 58.
Preference behind which this will be implemented:: None.
Is this feature enabled by default in sandboxed iframes? Yes.
Tests: only for the CSS parsing (similar to how -moz-touch-enabled is
currently tested). We do not currently have any testing infrastructure to
mock the OS calls for full test coverage. Nor do the Web Platform Tests
(and there are no bugs yet made against the WPTs to add them). Given that
other vendors have long shipped this regardless, and there have been no
major interop issues, I don't suspect this needs to be blocked on such
tests.
How stable is the spec: the last point of contention that I'm aware of was
resolved by other vendors a year ago when the "on-demand" feature was
dropped from the draft spec.
Security & Privacy Concerns: this exposes whether the user has pointer that
is finely controlled like a mouse, or more coarse-grained like a
touchscreen (or no pointer at all). It also exposes whether they have a
pointer capable of "hover" effects (like a mouse). This lets sites
distinguish between the user having a mouse-like device or touchscreen-like
device, and potentially other devices like stylii. It exposes a little more
fingerprintable information than -moz-touch-enabled, however it would be
trivial for anti-fingerprinting measures to always return a specific set of
values for mobiles vs desktops.
Web designer / developer use-cases: Allowing sites to definitively know
whether the user has a touch-capable device, mouse-like device, or
stylus-like device (or all three), so that appropriate styles can be served
for each case without having to resort to flimsier scripts to guess at
those capabilities.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: -moz-prefixed CSS cursor:zoom-in, zoom-out, grab, grabbing
The standard versions of these features have been in Firefox since at least version 27 and a deprecated notice has been up since October 2015. Edge supports the unprefixed versions, while Blink and WebKit support the "zoom" ones without prefixes and the "grab" ones behind the -webkit prefix. Bug for removal: https://bugzilla.mozilla.org/show_bug.cgi?id=879119 Deprecation notice: https://www.fxsitecompat.com/en-CA/docs/2015/prefixed-cursor-types-will-be-removed/ Link to standard: https://drafts.csswg.org/css-ui-3/#cursor ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: canvas 2D context mozDash and mozDashOffset.
The standard versions of these features have been in Firefox since version 27, the MDN pages have noted that they are deprecated since at least the middle of last year, and no addons on DXR show that they're used (except as fallbacks if the standard variant is missing). Other browsers have also supported the standard versions for at least as long. Bug for removal: https://bugzilla.mozilla.org/show_bug.cgi?id=931389 Deprecation notice: https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/setLineDash (in the Gecko-specific notes) Link to standard: https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-setlinedash ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: canvas getTransform() and setTransform(DOMMatrixInit) methods.
The canvas draft spec used to have a currentTransform attribute on 2D canvas context objects, which was implemented by Chrome (behind a runtime flag). We also ship our own similar (but non-standard) mozGetTransform and mozSetTransform methods. The draft spec has since changed to add a getTransform method returning a DOMMatrix, and a setTransform method that accepts a new DOMMatrixInit dictionary. It seems that the Chrome team intends to support these new methods instead of currentTransform, so I would like to implement them as well, and help push the spec forward. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=928150 Proposed preference behind which to implement: canvas.transform_extensions.enabled Draft spec: https://html.spec.whatwg.org/multipage/scripting.html#current-transformation-matrix Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=637940 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: CSS placeholder pseudo-element
As of Firefox 51, I intend to unprefix the ::placeholder pseudo-element on all platforms. The -moz prefixed version has been active for a long time now, all browsers support a prefixed version, and WebKit has just unprefixed it for their test preview of Safari. I've also recently unprefixed the related pseudo-class, :placeholder-shown, in bug 1069015. Bug to enable it: https://bugzilla.mozilla.org/show_bug.cgi?id=1069012 Link to standard: https://drafts.csswg.org/css-pseudo-4/#placeholder-pseudo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: -moz-prefixed Page Visibility API.
I intend to remove the prefixed version of the Page Visibility API, which consists of the mozvisibilitychange event and mozHidden and mozVisibilityState document properties. The unprefixed versions of these features have been available since Firefox 18, and a deprecation warning was issued on fxsitecompat.com in October 2015. All other engines have supported the unprefixed version for quite a while as well (IE11, Chrome 33, Safari 6.1). Bug for removal: https://bugzilla.mozilla.org/show_bug.cgi?id=812701 Deprecation notice: https://www.fxsitecompat.com/en-CA/docs/2015/prefixed-page-visibility-api-will-be-removed/ Link to standard: https://www.w3.org/TR/page-visibility/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship imageSmoothingEnabled and remove mozImageSmoothingEnabled.
Summary: ctx.imageSmoothingEnabled is a Canvas2D context property controlling the interpolation of images drawn to 2D canvases (especially useful for pixel art). Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=768072 Link to standard: https://html.spec.whatwg.org/multipage/scripting.html#image-smoothing Platform coverage: all. Estimated or target release: Firefox 52 Preference behind which this will be implemented: None. This has been unprefixed in Chrome since version 41, and it should ship unprefixed in Safari 10. Web platform tests now cover the feature as well. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: minlength attribute and tooShort validityState.
Summary: We already ship the HTML maxlength attribute with its associated tooLong validityState, and will now support its minlength/tooShort counterparts. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=932755 Link to standard: https://html.spec.whatwg.org/multipage/forms.html#the-maxlength-and-minlength-attributes Platform coverage: All Estimate of target release: Firefox 51 Preference behind which this will be implemented: None Chrome has shipped with minlength/tooShort since version 40. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: XMLHttpRequest parsing errors will yield a null document for web content, not one with a root.
Summary: XMLHttpRequests for web content (and WebExtensions) will now follow the spec and return a null response/responseXML in the event of a parsing error, rather than a document with a root. The web console will also log a more informative error. Non-WebExtension addons and other chrome code will continue to generate documents, for backwards compatibility. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=289714 Standard: https://xhr.spec.whatwg.org/#document-response Platform coverage: all. Estimated release: Firefox 50. Devtools bug: none needed. Other browsers: Chrome, Safari and Edge already follow the spec behavior. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: CSS4 :any-link pseudo-class
As of Firefox 50, I intend to unprefix the CSS4 :any-link pseudo-class on all platforms. It has been supported in Firefox for a long time now as :-moz-any-link, and has been aligned with the spec for several years as well (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=21070). Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=843579 Link to standard: https://drafts.csswg.org/selectors-4/#the-any-link-pseudo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
