Closed Bug 1619673 Opened 4 years ago Closed 3 years ago

Disable appcache in release

Categories

(Core :: Networking: HTTP, task, P3)

task

Tracking

()

RESOLVED FIXED
84 Branch
Iteration:
84.1 - Oct 19 - Nov 01
Tracking Status
firefox77 --- wontfix
firefox84 --- fixed

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)

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: nobody → valentin.gosu
Status: NEW → ASSIGNED
Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/f28b42617940
Disable appcache in release r=dragana
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77
Depends on: 1631097

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.

Status: RESOLVED → REOPENED
Flags: needinfo?(nhnguyen)
Resolution: FIXED → ---

(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?

Flags: needinfo?(mconca)

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.

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.

Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED

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.

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.

Flags: needinfo?(mconca)

(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!

Flags: needinfo?(mconca)
See Also: → 1633567

(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.

Flags: needinfo?(mconca)
Flags: needinfo?(nhnguyen)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: COVID-19
Type: defect → task
Blocks: omt-content

Can we reevaluate this now that 78 has branched?

Flags: needinfo?(mconca)

(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.

Flags: needinfo?(mconca)
Depends on: 1652585
Depends on: 1665355

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?

Flags: needinfo?(mconca)

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/

Iteration: --- → 84.1 - Oct 19 - Nov 01
Flags: needinfo?(mconca)

(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.

Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/bab939b79a05
Disable appcache in release r=dragana
Status: REOPENED → RESOLVED
Closed: 4 years ago3 years ago
Resolution: --- → FIXED

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

Thank you Hamish!

Target Milestone: mozilla77 → 84 Branch
You need to log in before you can comment on or make changes to this bug.