Disable appcache in release
Categories
(Core :: Networking: HTTP, task, P3)
Tracking
()
People
(Reporter: dveditz, Assigned: valentin)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-complete, site-compat, Whiteboard: [necko-backlog])
Attachments
(1 file)
+++ This bug was initially created as a clone of Bug #1237782 +++
We have disabled appcache in Nightly and Beta for a while (bug 1237782). We need to roll this pref-flip out to release to gain the confidence to remove the code entirely (bug 1584984)
Comment 1•4 years ago
|
||
It seems that browser.cache.offline.storage.enable
is true on late beta and release, otherwise false. Making that false on late beta and release is what this bug is about (and being prepared to flip it back if too problematic).
browser.cache.offline.enable
however is always true still and guards window.applicationCache
. Seems like we also need to plan removing that, unless we want to keep it around as a dummy interface forever, which might be okay...
Assignee | ||
Comment 2•4 years ago
|
||
Updated•4 years ago
|
Pushed by valentin.gosu@gmail.com: https://hg.mozilla.org/integration/autoland/rev/f28b42617940 Disable appcache in release r=dragana
Comment 4•4 years ago
|
||
bugherder |
Comment 5•4 years ago
|
||
Posted site compatibility note.
Comment 6•4 years ago
|
||
I'd like to request that we delay landing this until 79. With the stay-at-home orders during covid-19, enterprises may not be in a position to fix any resulting breakage. Delaying until 79 not only give more response time, but allows the current AppCache to continue working in 78, the next ESR release.
Assignee | ||
Comment 7•4 years ago
|
||
(In reply to Mike Conca [:mconca] from comment #6)
I'd like to request that we delay landing this until 79. With the stay-at-home orders during covid-19, enterprises may not be in a position to fix any resulting breakage. Delaying until 79 not only give more response time, but allows the current AppCache to continue working in 78, the next ESR release.
Have we considered the increased security risk coming from keeping this enabled on ESR?
The usage numbers for appcache are already very low. The risk of breakage is even lower, since we're not disabling the API, so no JS errors. We've received no reports when disabling in nightly and early beta. I think the reasoning I presented in bug 1631097 comment #1 should make this risk even lower. Do we think risk of breakage is higher than the increased attack surface is presents and the performance gain from disabling it?
Comment 8•4 years ago
|
||
Couldn’t we keep it enabled for one ESR release? I sympathize very much with the goal for stability presented here but AFAIU the breakage potential is really low, as Valentin mentions above. With that said, we’ve seen breakage from the weirdest side effects before.
Unrelated to the discussion, it’s uncommon and not very practical to re-open a bug without backing out the offending patch at the same time (except for re-opening a bug because the issue hasn’t been fully fixed). Having an open bug with the “issue” fixed through a patch invites misunderstandings. So let’s either back out the patch or resolve the bug again.
Updated•4 years ago
|
Comment 9•4 years ago
|
||
As Johann said, this bug should remain closed unless the patch that landed is backed out or it becomes more difficult to understand what is happening. You could file a new bug to un-disable appcache if you really need an open bug to monitor.
Comment 10•4 years ago
•
|
||
As of now, this would ship 2020-06-02 and Chrome's removal possibly 2020-06-23 or a month later. Shipping this with ESR 78 would mean to support it another full year. (I assume deprecations do not happen within an ESR release.)
It doesn't even take an hour to change AppCache into a simple ServiceWorker and to learn the basics around it.
https://thomashunter.name/posts/2019-04-30-service-workers
The Application Cache came with a few footguns. For example, if the cache file is accessed and has been altered, this would signify that the site has been updated and the browser should rebuild the cache. However, if the filename for the cache was added to the cache file, the cache would cache the manifest and the user would never download newer updates. See Application Cache is a Doucebag for more footguns.
Comment 11•4 years ago
•
|
||
Nhi and I have reviewed this change within our respective organizations and have made the decision to postpone disabling AppCache until at least Firefox 79.
Assignee | ||
Comment 12•4 years ago
|
||
(In reply to Mike Conca [:mconca] from comment #11)
Nhi and I have reviewed this change within our respective organizations and had made the decision to postpone disabling AppCache until at least Firefox 79.
Can you file a new bug to reenable it? Thanks!
Comment 13•4 years ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #12)
(In reply to Mike Conca [:mconca] from comment #11)
Nhi and I have reviewed this change within our respective organizations and had made the decision to postpone disabling AppCache until at least Firefox 79.
Can you file a new bug to reenable it? Thanks!
Bug 1633567 filed.
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 14•4 years ago
•
|
||
Can we reevaluate this now that 78 has branched?
Comment 15•4 years ago
|
||
(In reply to Anne (:annevk) from comment #14)
Can we reevaluate this now that 78 has branched?
Nhi and I discussed this. Looking at Google, they are proceeding with caution, pushing the removal of appcache out a bit more to Chrome M85 (mid-August) while also setting up a reverse origin trial (devs can get a token to keep appcache working for 6 more weeks). Firefox has no ability to do reverse origin trials.
More info here:
https://web.dev/appcache-removal/
https://bugs.chromium.org/p/chromium/issues/detail?id=582750#c47
Based on that, we feel the best approach is to begin disabling this in Firefox 80 (late August release) to better align with Chrome's release, and to roll it out to the user population via a staged rollout to better mitigate the risk of accidental breakage.
Comment 16•4 years ago
|
||
Mike, we're now on track for 82 which I think means we'd be rolling out after the Chrome reverse origin trial finishes (late October).
Can we go ahead with disabling this now?
Assignee | ||
Comment 17•4 years ago
|
||
Given that we plan to rollout the pref to release in 81-83 this is expected to land in 84.
https://experimenter.services.mozilla.com/experiments/staged-rollout-for-appcache-removal/
Comment 18•4 years ago
|
||
(In reply to Matt Woodrow (:mattwoodrow) from comment #16)
Mike, we're now on track for 82 which I think means we'd be rolling out after the Chrome reverse origin trial finishes (late October).
Can we go ahead with disabling this now?
Chrome 85 disabled AppCache by default in August, but the Chrome reverse origin trial doesn't end until M90, which is currently April 2021. That said, I think our biggest concern was potential breakage for Firefox Enterprise customers. Now that ESR 78 is available (with AppCache enabled) and the experiment is back on track to do a staged rollout, I think we are in good shape.
Comment 19•4 years ago
|
||
Pushed by valentin.gosu@gmail.com: https://hg.mozilla.org/integration/autoland/rev/bab939b79a05 Disable appcache in release r=dragana
Comment 20•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Comment 21•3 years ago
|
||
FYI, Docs work for FF84 now done:
- BCD updated
- Using the application cache
- I updated note to say "do not use" (rather than just strong recommendation) and that feature is "removed in FF84". The note is now up the top of the page ahead of the deprecation macros, because to my mind it is more important than those.
- Added "further info" link to useful blog https://web.dev/appcache-removal/
- Release note updated.
More info on docs work for this here: https://github.com/mdn/sprints/issues/3901
Assignee | ||
Comment 22•3 years ago
|
||
Thank you Hamish!
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Description
•