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
Re: Intent to unship: Application Cache API
I don't think so. On Tue, 23 Feb 2021 at 14:50, Jeff Muizelaar wrote: > > Is the list of sites that have enrolled in Chrome's reverse origin trial > public? > > -Jeff > > On Tue, Feb 23, 2021 at 7:11 AM Valentin Gosu wrote: > > > > The storage backing for Application Cache has been completely disabled > > starting with Firefox 84 [1]. That means the current > > window.applicationCache object is not really useful and only exists > > for backward compatibility. The plan is to remove it. > > > > We intend to do this in two stages: First we disable the API for > > Nightly and Early beta [2] followed by an eventual disabling and > > removal in Release [3]. The removal in Release is expected to happen > > after Chrome's origin trial is completed [4]. > > > > The risk associated with removing this API is slightly higher than > > with disabling the storage from appCache due to the greater chance it > > could cause JS exceptions to be thrown if websites don't check if the > > API exists. > > However, we have successfully unshipped this from insecure origins in > > the past so we don't expect major issues. > > > > The current use stats for the window.applicationCache in Beta 86 > > (2021/01/25 - 2021/02/17) are as follows: > > 018.91B (99.51%) - Not used > > 1244.32M (0.49%) - Used > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1619673 > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1677719 > > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1677718 > > [4] https://web.dev/appcache-removal/ > > ___ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: Application Cache API
Is the list of sites that have enrolled in Chrome's reverse origin trial public? -Jeff On Tue, Feb 23, 2021 at 7:11 AM Valentin Gosu wrote: > > The storage backing for Application Cache has been completely disabled > starting with Firefox 84 [1]. That means the current > window.applicationCache object is not really useful and only exists > for backward compatibility. The plan is to remove it. > > We intend to do this in two stages: First we disable the API for > Nightly and Early beta [2] followed by an eventual disabling and > removal in Release [3]. The removal in Release is expected to happen > after Chrome's origin trial is completed [4]. > > The risk associated with removing this API is slightly higher than > with disabling the storage from appCache due to the greater chance it > could cause JS exceptions to be thrown if websites don't check if the > API exists. > However, we have successfully unshipped this from insecure origins in > the past so we don't expect major issues. > > The current use stats for the window.applicationCache in Beta 86 > (2021/01/25 - 2021/02/17) are as follows: > 018.91B (99.51%) - Not used > 1244.32M (0.49%) - Used > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1619673 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1677719 > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1677718 > [4] https://web.dev/appcache-removal/ > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: Application Cache API
The storage backing for Application Cache has been completely disabled starting with Firefox 84 [1]. That means the current window.applicationCache object is not really useful and only exists for backward compatibility. The plan is to remove it. We intend to do this in two stages: First we disable the API for Nightly and Early beta [2] followed by an eventual disabling and removal in Release [3]. The removal in Release is expected to happen after Chrome's origin trial is completed [4]. The risk associated with removing this API is slightly higher than with disabling the storage from appCache due to the greater chance it could cause JS exceptions to be thrown if websites don't check if the API exists. However, we have successfully unshipped this from insecure origins in the past so we don't expect major issues. The current use stats for the window.applicationCache in Beta 86 (2021/01/25 - 2021/02/17) are as follows: 018.91B (99.51%) - Not used 1244.32M (0.49%) - Used [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1619673 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1677719 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1677718 [4] https://web.dev/appcache-removal/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to prototype and ship: :user-valid and :user-invalid pseudo-classes.
On 2/23/21 09:24, Anne van Kesteren wrote: On Mon, Feb 22, 2021 at 2:59 PM Emilio Cobos Álvarez wrote: Let me know if you have any objections about this change, but I think having a prefixed pseudo-class for this is not a great state of affairs. This seems reasonable, but I think we should define the processing model for them in the HTML Standard as well, to ensure everyone can align on when exactly these are supposed to match. The original spec text for :user-invalid was pretty flexible in terms of when it can match. My understanding is that that was kind of intentional (cc'ing fantasai who was part of those discussions). But yeah I tend to agree we probably want to define more precisely when these must match and maybe even when they may match. -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to prototype and ship: :user-valid and :user-invalid pseudo-classes.
On 2/23/21 11:52, Xidorn Quan wrote: Please head up in CSS working group about this, and probably ask for a resolution on no objection for us to ship it, as this spec is still in draft. Hmm, is it? https://www.w3.org/TR/selectors-4/#user-pseudos has had :user-invalid for quite a while, and we and other engines ship a lot of stuff in selectors-4. (I just added spec text for :user-valid, but it was noted in the non-draft spec that there was a resolution to add it as well). Anyhow not particularly trying to avoid this, just trying to clarify the situation. A heads-up probably wouldn't hurt anyways, and per Anne's comments we might want some html spec text as well. -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to prototype and ship: :user-valid and :user-invalid pseudo-classes.
On Tue, Feb 23, 2021, at 12:59 AM, Emilio Cobos Álvarez wrote: > Standard: https://drafts.csswg.org/selectors/#user-pseudos > > Other browsers: No signal from other vendors, though we've shipped this > functionality for quite a while and the CSS working group considers it > useful, see discussions: > > * https://lists.w3.org/Archives/Public/www-style/2012Aug/0749.html > * https://lists.w3.org/Archives/Public/www-style/2015Sep/0111.html > > I'm hoping that unprefixing it in Gecko will serve as a bit of a nag to > other browsers. Please head up in CSS working group about this, and probably ask for a resolution on no objection for us to ship it, as this spec is still in draft. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to prototype and ship: :user-valid and :user-invalid pseudo-classes.
On Mon, Feb 22, 2021 at 2:59 PM Emilio Cobos Álvarez wrote: > Let me know if you have any objections about this change, but I think > having a prefixed pseudo-class for this is not a great state of affairs. This seems reasonable, but I think we should define the processing model for them in the HTML Standard as well, to ensure everyone can align on when exactly these are supposed to match. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
