[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Closed Bug 1237782 Opened 9 years ago Closed 5 years ago

Remove support for appcache storage in Nightly and early beta

Categories

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

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla71
Tracking Flags:
Tracking Status
e10s - ---
firefox71 --- fixed

People

(Reporter: ehsan.akhgari, Assigned: jkt)

References

Details

(Keywords: dev-doc-complete, site-compat, Whiteboard: [necko-backlog])

Attachments

(1 file, 1 obsolete file)

Bug 1237782 - Remove http override and add appcache pref
47 bytes, text/x-phabricator-request
Details | Review
This is a tracker for the work required to stop supporting appcache.
Depends on: 1237783
What is your timeline for this? It seems exceptionally early to consider doing it.
(In reply to Ben Kelly [:bkelly] from comment #1) > What is your timeline for this? It seems exceptionally early to consider > doing it. It's still unclear, since the plan is not finalized yet. This bug just tracks the work necessary for now.
Love the work you're doing on Service Workers, but please don't remove AppCache until all major browsers fully implement Service Workers. I'm the maintainer of DevDocs (http://devdocs.io), which is probably one of the most popular web app out there (50k+ monthly users) that uses AppCache extensively. It would be very annoying and time-consuming to have to implement and support both APIs in one app in order to make it offline-capable.
> Love the work you're doing on Service Workers, but please don't remove AppCache until all major browsers fully implement Service Workers. +100. We're running a static app hosting platform and this would break most of our customers' offline support at the moment.
I must also say this is seems far too early for us. We build Construct 2, a major HTML5 game engine, and despite the hate AppCache gets it has been working solidly for us as an offline solution for games for years now. I made a significant effort to port our offline support to Service Worker recently, and was not able to get it working with the same feature parity as AppCache. The main problem is fetch()/cache.addAll() do not currently support cache control options (crbug.com/453190, mozilla bug 1120715). This means at the point of upgrade, it is extremely difficult to actually hit the network again and not just get something stale from the browser's HTTP cache, thereby rendering the web app in a permanently stale state. Given I am not aware of any SW library that has feature-parity with AppCache (especially loading a list of resources from an external file, and guaranteeing updates are atomic even if interrupted halfway through), and that my own efforts were stymied by the apparent incompleteness of APIs available in SW, I feel it is unreasonably premature to announce deprecation of AppCache.
fwiw, this bug blocks the removal of the previous http cache implementation (appcache uses it, but nothing else does). That's a sizable piece of code with known bugs.
We can fix bug 1120715 before doing this. But to Thibaut and others' point: AppCache is going away. If you have major properties using AppCache, now is the right time to start porting it to use service workers instead. We're especially interested in knowing what sorts of stuff blocks people from doing this (comment 6 is a great example, thanks Ashley!)
Depends on: 1120715
I know AppCache is going away. My point is I already tried and failed to move to SW. I don't think you should deprecate a feature until the alternative is mature and widely supported.
> AppCache is going away. If you have major properties using AppCache, now is the right time to start porting it to use service workers instead. It's certainly a good time to try them out and maybe even use them in production, but it's plain impossible to use them *instead* of AppCache, which is the main problem for us. We'll have to use the widely supported, mature AppCache for its use case anyway, in order to have more than half of customers be able to use our apps offline. So removing it from FF at this point in time would just be forcing developers to maintain both at the same time with possibly different behavior for a big chunk of end users.
(In reply to ashley from comment #9) > I know AppCache is going away. My point is I already tried and failed to > move to SW. I don't think you should deprecate a feature until the > alternative is mature and widely supported. Like I said before, if the issue is lack of RequestCache support, that's something that we're actively working on. If there are other issues, please file bugs! (In reply to Sebastian Kippe from comment #10) > > AppCache is going away. If you have major properties using AppCache, now is the right time to start porting it to use service workers instead. > > It's certainly a good time to try them out and maybe even use them in > production, but it's plain impossible to use them *instead* of AppCache, > which is the main problem for us. Why is that? When a page is controlled by a service worker, AppCache is bypassed for it completely (see bug 1163545 where we did this in Firefox, I believe Chrome is working on this as well.) With this, you should be able to write apps which use AppCache as a fallback for browsers that do not support service workers. > We'll have to use the widely supported, mature AppCache for its use case > anyway, in order to have more than half of customers be able to use our apps > offline. So removing it from FF at this point in time would just be forcing > developers to maintain both at the same time with possibly different > behavior for a big chunk of end users. We're not intending to remove AppCache from Firefox _right now_, as we still haven't shipped service workers. :-) Starting with Firefox 44, we'll ship support for service workers, and deprecate AppCache at the same time (Firefox will start issuing Web Console warnings for pages loaded through AppCache). This bug is where the work to eventually remove support for AppCache is being done, but there will be time for transitioning the current consumers of AppCache to service workers. Also please note that we still don't have a timeline on when we're going to remove AppCache. What's really helpful at this stage is to know about problems that would prevent websites from using AppCache as a fallback in case the browser doesn't support service workers. If you know of any such issues, please file bugs, that would be much appreciated.
Blocks: 814330
No longer blocks: 814330
Whiteboard: [necko-backlog]
Removing this has been approved by Mike Taylor of web compat, so we're going to go ahead and kill this off. Remaining work to do: 1) Feature Detection: 'applicationCache' in window - should return undefined (or false?) window.applicationCache - should be falsey so homebrew Modernizr-like tests like the following do not return true: - https://github.com/tsechingho/modernizr-rails/blob/188fd3440d21eda996dd735aded9a4fe4b4015e4/vendor/assets/javascripts/modernizr-applicationcache.js 2) API Neutering: window.applicationCache - API usages should be a no-op, e.g., the following code should not throw (because not everyone checks for object existence, etc.): - https://github.com/16patsle/Pokedex/blob/9b4affaaca977e14e73f39c507d1f5ffa6521cf1/_assets/js/script.js 3) evicting existing caches and its storage on disk needs a follow up bug 4) some sort of a public announcement?
tracking-e10s: --- → ?
Blocks: 1252860
Jim, Can you or Mike please write a blog post about this? I would like something I can refer to when the angry hordes complain that service workers took away their http offline support. Thanks.
I have already posted the site compatibility doc; see my comment 2.
(In reply to Kohei Yoshino [:kohei] from comment #16) > I have already posted the site compatibility doc; see my comment 2. Yes, and we got flak for it because its still pretty early days for service workers. If this is being driven by e10s support then a blog post stating that would be great.
I'm happy to blog about it, angry hordes can be directed to https://miketaylr.com/posts/ in the next few days.
Has comment #6 been addressed in the SW spec? Specifically the need for an atomic "cache.addAll" that doesn't write/overwrite anything in the cache object until (and only if) all requests have succeeded? (did a quick read of the spec but couldn't figure it out) This is an essential feature for people moving from AppCache to SW.
Thanks Mike! (In reply to Thibaut Courouble from comment #19) > Has comment #6 been addressed in the SW spec? Specifically the need for an > atomic "cache.addAll" that doesn't write/overwrite anything in the cache > object until (and only if) all requests have succeeded? (did a quick read of > the spec but couldn't figure it out) As of FF46 Cache.addAll() only commits to storage if all requests result in a 20x success. In addition we also support RequestCache now for controlling interaction with HTTP cache.
(In reply to Ben Kelly [:bkelly] from comment #20) > As of FF46 Cache.addAll() only commits to storage if all requests result in > a 20x success. > > In addition we also support RequestCache now for controlling interaction > with HTTP cache. Great, thanks!
It sounds like SW has only just reached the point where we can hopefully start using it equivalently to AppCache. Please allow us sufficient time to implement and test offline support based on SW. If you release these SW updates and remove AppCache in the same release or close together, you put us on a super tight deadline to move over without losing offline support at some point. For a framework like Construct 2, our own release cycle normally involves 2-3 months of having regular beta releases before making a stable release, and others will be slower. Then on top of that our users then need to update, and will have their own testing and release cycles beyond that. I am worried during this process you will pull AppCache support before everyone's ready. This wouldn't be half as bad if there was a convincing well-tested polyfill for AppCache based on SW, and as far as I'm aware there is none - to me this tallies with my previous difficulties trying to do the same - I guess nobody else has been able to do it either!
(In reply to Ben Kelly [:bkelly] from comment #15) > Jim, > > Can you or Mike please write a blog post about this? I would like something > I can refer to when the angry hordes complain that service workers took away > their http offline support. > > Thanks. jduel is going to take ownership of this work. For e10s we are going to do manual testing to be sure things are working. e10s rollout and ending appcache will not be linked, so we'll likely have a release or two with e10s enabled and no e10s appcache test coverage running in automation. Existing non-e10s appcache testing will continue. For consumers of appcache cc'd here, we would appreciate your help in testing your use of appcache with e10s enabled on Nightly, or list the sites that use it so our qa team can test manually.
(In reply to Jim Mathies [:jimm] from comment #14) > Removing this has been approved by Mike Taylor of web compat, so we're going > to go ahead and kill this off. > > Remaining work to do: > > 1) Feature Detection: > > 'applicationCache' in window > - should return undefined (or false?) > > window.applicationCache > - should be falsey so homebrew Modernizr-like tests like the following do > not return true: > - > https://github.com/tsechingho/modernizr-rails/blob/ > 188fd3440d21eda996dd735aded9a4fe4b4015e4/vendor/assets/javascripts/modernizr- > applicationcache.js > > 2) API Neutering: > > window.applicationCache > - API usages should be a no-op, e.g., the following code should not throw > (because not everyone checks for object existence, etc.): > - > https://github.com/16patsle/Pokedex/blob/ > 9b4affaaca977e14e73f39c507d1f5ffa6521cf1/_assets/js/script.js > > 3) evicting existing caches and its storage on disk needs a follow up bug > > 4) some sort of a public announcement? I don't quite follow this comment. Is this a set of questions yet to be decided or is it a list of behavioral changes we want to enforce when appcache is disabled? I've recently landed a patch that allows disabling appcache by turning a pref (actually few prefs) - bug 1237783. It makes window.applicationCache be 'undefined'. From what you write here it seems like windows.applicationCache should be a blackhole implementation, that would mean some more work to do. So, what is the preference and why?
Flags: needinfo?(jmathies)
Yea, wouldn't a blackhole implementation make it harder to feature detect that appcache is not implemented?
A blackhole implementation (TIL a term for that exists) is to prevent breaking pages that do similar things to: if (window.applicationCache.status == window.applicationCache.UPDATEREADY) { window.applicationCache.update(); } Basically we don't want to create TypeErrors where they did not exist before.
(In reply to Honza Bambas (:mayhemer) from comment #24) > I don't quite follow this comment. Is this a set of questions yet to be > decided or is it a list of behavioral changes we want to enforce when > appcache is disabled? behavior changes. These were suggestions by Mike in an email thread. I'll leave it to him to explain his reasoning.
Flags: needinfo?(jmathies)
(In reply to Jim Mathies [:jimm] from comment #14) ... > 4) some sort of a public announcement? As discussed in the e10s cross-functional meeting today, I would prefer we engage with devrel and let them lead with this communication.
Can someone please respond to the concerns voiced by developers and library authors in this very thread? The latest being https://bugzilla.mozilla.org/show_bug.cgi?id=1237782#c22 for example. Thank you.
(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #28) > (In reply to Jim Mathies [:jimm] from comment #14) > ... > > 4) some sort of a public announcement? > > As discussed in the e10s cross-functional meeting today, I would prefer we > engage with devrel and let them lead with this communication. SGTM. For other people following along in the bug, the timing on this will not be as dramatic as Comment #14 (or other conversations on Twitter) might lead you to believe. We're still investigating telemetry and crawler data and want to provide something developers can migrate to (like a service worker-based AppCache polyfill or similar).
Thanks. That #14 was a bit scary to those of us depending on it in production.
No longer blocks: 1250331
As a member of the general public: I do not understand why are we deprecating AppCache. Since when is it OK to disable specs when a better one shows up? Also since when is it OK to do that without even warning loudly about the plans? Loudly, like a giant stomping from far away "ME! ME DISLIKES APPCACHE! ME SMASHES APPCACHE!" *stomp stomp stomp* As a member of the devrel team: I think that this should be better addressed in a blog post that someone from the team responsible for switching AppCache off should write, so everyone can understand the reasons and ask questions to those people. I do not think we are equipped to answer those as the motivation for this change seems purely Necko technical. I'd rather warn people beforehand, pointing them to that post and help them with *migration* paths than apply emergency *mitigation* strategies when a lot of people find their stuff stopped working in the newer Firefox... And to reiterate, I do not understand why are we doing this and breaking the web.
(In reply to Soledad Penades [:sole] [:spenades] from comment #32) > As a member of the general public: I do not understand why are we > deprecating AppCache. Since when is it OK to disable specs when a better one > shows up? Also since when is it OK to do that without even warning loudly ... See spec notice for AppCache https://html.spec.whatwg.org/multipage/browsers.html#offline > This feature is in the process of being removed from the Web platform. > (This is a long process that takes many years.) Using any of the offline > Web application features at this time is highly discouraged. Use service > workers instead.
(In reply to Soledad Penades [:sole] [:spenades] from comment #32): > I do not understand why are we doing this and breaking the web Firstly, I don't think removing appcache breaks the web. Given it can only really provide a 1:1 mapping of request/response, I don't think it's possible to build a site that requires appcache, unless you try and use the API without feature detection, although you could mitigate that by providing a no-op API. Removing appcache would remove the offline feature from some websites, but I don't think that breaks the web. A win for progressive enhancement! Here's why appcache should be removed from the platform: 1. It should never have been available over HTTP, it's a MITM disaster Say you use an internet connection that isn't end-to-end under your control, eg the wifi at a bar, or in a country that likes to do dodgy things with web traffic. You visit http://www.bbc.co.uk/news, but a MITM injects a manifest attribute into the HTML tag, and some other javascript to mess with the content of the page. The manifest points to http://www.bbc.co.uk/robots.txt. They intercept the request for robots.txt providing a valid manifest, which caches their tampered BBC news page, along with their evil JS etc etc. Now, even when you leave the evil wifi, the BBC page is perma-tampered. The browser's request for the manifest doesn't 404 (robots.txt exists), but it doesn't validate as a manifest, so the browser carries on with the cache it already has. Your copy of the BBC is infected until you manually clear storage. Note that the site doesn't need to use appcache to be open to this attack, it just has to be served over HTTP, and viewed in a browser that supports appcache. For this reason, the first step browsers should take is to disable appcache for insecure contexts. 2. It leaks information about resources on other origins The manifest update process fails if any response's status is not-ok (404, 403, 500 etc etc). Unfortunately, this happens for cross-origin content too, so you can use appcache to snoop on the user's activity on other sites. If the other site has a signed-in-only area that 403s if not signed in, another website can use appcache to detect this. 3. Master entries are an attack vector Say I created a competitor to https://gabrielecirulli.github.io/2048/, and I wanted to get the upper-hand in evil ways, well I can thanks to appcache! Appcache auto-caches any page that points to a manifest, so all I have to do is trick the user into loading lots of versions of their page with random querystrings. Each successful page load adds another master entry to their cache, which must be re-requested in order to update the cache. Here's an example of the attack https://output.jsbin.com/medoke/quiet So next time 2048 wants to update, the user may have to download 1000s of resources. If that update fails, the user remains on an old version, giving my product an advantage. Interestingly, Safari prevents appcache from operating within an iframe, which prevents the attack in my demo (I want Chrome to do the same), but there are other ways to launch this attack, especially if I can get a URL into master entry list which will later start 404ing or 500ing, since that'll instantly lock the user into a given version. So yeah, appcache is pretty bad.
@Sole, do we have any numbers of current AppCache usage? I have the feeling that the downsides of it were so big that we have a very, very limited supply of websites actually leveraging it. I saw some usage in FxOS apps but they have been deprecated now as well... But I'd like to be convinced. Regardless, I think I should back Jake here (even though I have been an avid supported of AppCache before) in: > Firstly, I don't think removing appcache breaks the web. Given it can only really provide a 1:1 mapping of request/response, I don't think it's possible to build a site that requires appcache, unless you try and use the API without feature detection, although you could mitigate that by providing a no-op API. > Removing appcache would remove the offline feature from some websites, but I don't think that breaks the web. A win for progressive enhancement! I think AppCache was a mistake, and we should move further. Which we can do without breaking the web.
Flags: needinfo?(sole)
There has been discussion of usage with telemetry counters in private email threads. I think the fact that they were private and not on dev-platform or in this bug has probably contributed to the confusion around this issue. The current state is we need more information. We don't think the probes we have provide the right infromation. We're trying to figure out what probes we need.
I'm really happy about deprecating AppCache (after all we all knew it was a... a... well, what Jake said it was). But I'm not cool with doing things all of a sudden and without warning developers/users or providing no explanation whatsoever and no transition path. I am surprised at the lack of empathy here, some people do not have time or resources to update their code on a short notice and things might break for some. I don't think that's a good thing. And moving to service workers is not immediate either. Which is why the announcement puzzled me and a lot more people who have kept it quiet on this bug. I guess comment 33 is pointing to the root of the reason, because otherwise it looks as if this is part of a Necko old code spring cleaning routine. I hope you understand how this looks like to the average developer: "why should internal Firefox maintenance break my websites?" Jan, telemetry people are collecting data on how much people are using AppCache - I don't have access to that. Thanks for providing your offline expertise, Jake. I also saw that Chrome are going to remove support for AppCache over HTTP only, any plans for HTTPS? https://bugs.chromium.org/p/chromium/issues/detail?id=588931
Flags: needinfo?(sole)
(In reply to Soledad Penades [:sole] [:spenades] from comment #37) > Thanks for providing your offline expertise, Jake. I also saw that Chrome > are going to remove support for AppCache over HTTP only, any plans for > HTTPS? https://bugs.chromium.org/p/chromium/issues/detail?id=588931 There's a ticket for it, but no timeline yet https://bugs.chromium.org/p/chromium/issues/detail?id=582750
I wanted to weigh in with an objection to removing AppCache any time soon. Today, AppCache is in almost every browser (and every latest-version browser). Service Worker is starting to ship in some browsers, but there are major browsers that have not yet started to ship. This means that if I want to build an application that uses the "fast navigation" capability that has been part of the web since 2011, I have to start off by using AppCache for maximum reach. I could just leave IE, Edge, Safari and the old Android browser in the cold, but the performance difference is pretty significant (even more so on older browsers), so it makes sense for me to start off with AppCache. Service Worker is indeed easier to work with and adds additional capabilities, so I'll probably enhance my application with Service Worker once things are humming along, and the Service Worker spec expects this outcome: if you have specified a Service Worker, the spec tells browsers to ignore a legacy AppCache. While it may be nice to believe that people will implement Service Worker first and backfill AppCache for older browsers, it makes more sense to start with greater reach (AppCache) and "progressively enhance" with better features. The web has always been good at this transition: we support querySelectorAll *and* old DOM APIs, fetch *and* XHR, and plan to support modules *and* scripts. This allows application, library and framework authors to maintain best-effort support for existing capabilities and transition up to newer facilities as they mature and stabilize. (AppCache may not be used so heavily in the wider web, but it's used more in applications, and while it's technically compatible to fall back to regular HTTP requests, the performance degradation would be pretty acute. Not every one of these apps is still maintained by the original author, and the new maintainers might find it very difficult to quickly upgrade to Service Worker.)
Maybe a concrete example of why removing appcache completely now is a bad idea: My number 1 use of appcache is when I use http://devdocs.io/ during travel (subway, flight, train). But I use it every day. I wouldn't mind securing the issues mentioned in comment 34 though.
Hi Jake, I'd like to understand your security points better. In particular, it'd be useful to understand how SW address these issues. (In reply to Jake Archibald from comment #34) > 1. It should never have been available over HTTP, it's a MITM disaster So this one obviously is by making SW HTTPS-only (it sounds like Chrome's plans for now are to move appcache to HTTPS-only). > 2. It leaks information about resources on other origins So IIUC you're saying appcache can observe non-200 replies from other origins, right? What's the SW approach to cross-origin requests? > 3. Master entries are an attack vector This one is a little more involved -- can you walk me through how SW addresses it?
Depends on: 1262921
(In reply to Julien Wajsberg [:julienw] from comment #40) > Maybe a concrete example of why removing appcache completely now is a bad > idea: Just a reminder that now is not like, now-now. If and when this happens it will be in future releases, which will ride the trains like everything else. I've filed Bug 1262921 to make sure we have our telemetry story straight before making the decision on when. (and given that devdocs.io is actively maintained, I can't imagine that migrating to SW is beyond them -- we'll have a migration story as part of this plan too). Look forward to some blog posts on the Hacks blog to talk about timing, tooling and data.
(In reply to Dave Herman [:dherman] from comment #41) > (In reply to Jake Archibald from comment #34) > > > 1. It should never have been available over HTTP, it's a MITM disaster > > So this one obviously is by making SW HTTPS-only (it sounds like Chrome's > plans for now are to move appcache to HTTPS-only). Yep! > > 2. It leaks information about resources on other origins > > So IIUC you're saying appcache can observe non-200 replies from other > origins, right? Yeah. You can't tell the difference between a cross-origin 302/404/500/network-failure, but you can tell the difference between one of those things vs 200. > What's the SW approach to cross-origin requests? fetch('//other-origin/hello.js') …will reject if the resource doesn't have CORS headers, or the network fails. fetch('//other-origin/hello.js', {mode: 'no-cors'}) …will reject if the network fails. Otherwise it resolves with an "opaque" response. You're allowed to use it in response to requests that can accept an opaque response (img/audio/video/js/css etc etc), but you cannot access its content with script, and you cannot access its status code. It could be a 404, or a 200, you can't tell the difference. cache.addAll(requests) …rejects if one of the requests fails or returns a 404 response. It always rejects if the request is 'no-cors' and points to another origin. You can use the lower-level cache.put(request, response) if you want to store opaque responses, or deliberately want to cache a 404 etc. > > 3. Master entries are an attack vector > > This one is a little more involved -- can you walk me through how SW > addresses it? SW doesn't have a master entries equivalent. The only thing that's cached automatically is the SW script itself & scripts it imports. You can write your SW so it adds page to the cache as it's requested, but it isn't forced upon you.
https://github.com/kenchris/jakecache is uses ServiceWorkers to polyfill appcache, for anyone affected & looking for a quick fix.
What's the likely timeframe for removal of AppCache on secure origins? The Chrome team say they have "no such plans" to do this in this thread: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/UKF8cK0EwMI/discussion
(In reply to Jeff from comment #45) > What's the likely timeframe for removal of AppCache on secure origins? The > Chrome team say they have "no such plans" to do this in this thread: We just landed some telemetry that will help us make these kinds of decisions in Bug 1262921.
(In reply to Mike Taylor [:miketaylr] from comment #46) > (In reply to Jeff from comment #45) > > What's the likely timeframe for removal of AppCache on secure origins? The > > Chrome team say they have "no such plans" to do this in this thread: > > We just landed some telemetry that will help us make these kinds of > decisions in Bug 1262921. Thanks Mike, I saw that. I'm really after something very rough. Is it likely to be months, a year or many years? For developers who have to solve this right now, it looks like we have to write things twice, once with ServiceWorkers for the distant future and once with AppCache for the present. I know that Firefox & Chrome have recently got ServiceWorker support, but not all end users are on the latest versions and some will be using other browsers. It does seem really early to be doing this - echoing comment 22, there ought to be a "convincing well-tested polyfill for AppCache based on SW, and as far as I'm aware there is none".
We've also got an e10s-related bug for this (1252860) and a handful of distracting tests related to appcache. Knowing even a rough timeframe for this would help us be able to plan what the e10s overlap needs to be.
Blocks: 1285476
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Blocks: 1350544
Blocks: 1354175
Blocks: 740124
Blocks: 1569999
Depends on: 688937
Depends on: 755652
Blocks: 688937
No longer depends on: 688937
Blocks: 755652
No longer depends on: 755652
Blocks: 1500586
Blocks: 818101
Blocks: 1533134
Blocks: 863382
Blocks: 1454921
Blocks: 1409246
Pushed by jkingston@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e3f06f11de62 Remove http override and add appcache pref r=baku
Backout by aiakab@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/fb0d469e8a7f Backed out changeset e3f06f11de62 for causing browser-chrome failure on automation.py CLOSED TREE
Blocks: 1579444
Pushed by jkingston@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7dc9a45ef7d6 Remove http override and add appcache pref r=baku
Backout by csabou@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/440b7beb9e76 Backed out changeset 7dc9a45ef7d6 for causing browser chrome failures on browser_disableAppcache.js CLOSED TREE

Whoops I messed up a rebase, pushing to try first. But should be fine to go back in after.

Flags: needinfo?(jkt)
Pushed by jkingston@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8c25acd6a557 Remove http override and add appcache pref r=baku

Backed out changeset 8c25acd6a557 (bug 1237782) for wpt failures at controller-on-disconnect.https.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/b5bb9f7895378840d6250ae81777f621e95003d8

**Push with failures:**https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=8c25acd6a55708eb03eee9d05d1a51f6f1e68eb2&selectedJob=265502866

Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=265502866&repo=autoland&lineNumber=8748

Log snippet:
[task 2019-09-07T09:10:23.622Z] 09:10:23 INFO - TEST-START | /service-workers/service-worker/controller-on-disconnect.https.html
[task 2019-09-07T09:10:23.625Z] 09:10:23 INFO - Closing window 112
[task 2019-09-07T09:11:03.781Z] 09:11:03 INFO -
[task 2019-09-07T09:11:03.781Z] 09:11:03 INFO - TEST-UNEXPECTED-TIMEOUT | /service-workers/service-worker/controller-on-disconnect.https.html | controller is cleared on disconnected window - Test timed out
[task 2019-09-07T09:11:04.220Z] 09:11:04 INFO - TEST-UNEXPECTED-TIMEOUT | /service-workers/service-worker/controller-on-disconnect.https.html | expected OK
[task 2019-09-07T09:11:04.220Z] 09:11:04 INFO - TEST-INFO took 40593ms
[task 2019-09-07T09:11:04.864Z] 09:11:04 INFO - Closing logging queue
[task 2019-09-07T09:11:04.864Z] 09:11:04 INFO - queue closed
[task 2019-09-07T09:11:04.872Z] 09:11:04 INFO - Setting up ssl
[task 2019-09-07T09:11:04.892Z] 09:11:04 INFO - certutil |
[task 2019-09-07T09:11:04.908Z] 09:11:04 INFO - certutil |
[task 2019-09-07T09:11:04.923Z] 09:11:04 INFO - certutil |
[task 2019-09-07T09:11:04.923Z] 09:11:04 INFO - Certificate Nickname Trust Attributes
[task 2019-09-07T09:11:04.923Z] 09:11:04 INFO - SSL,S/MIME,JAR/XPI
[task 2019-09-07T09:11:04.923Z] 09:11:04 INFO -
[task 2019-09-07T09:11:04.923Z] 09:11:04 INFO - web-platform-tests CT,,
[task 2019-09-07T09:11:04.923Z] 09:11:04 INFO -
[task 2019-09-07T09:11:07.683Z] 09:11:07 INFO - adb Granting important runtime permissions to org.mozilla.geckoview.test
[task 2019-09-07T09:11:08.945Z] 09:11:08 INFO - adb launch_application: am start -W -n org.mozilla.geckoview.test/org.mozilla.geckoview.test.TestRunnerActivity -a android.intent.action.MAIN --es env9 MOZ_DISABLE_NONLOCAL_CONNECTIONS=1 --es env8 R_LOG_DESTINATION=stderr --es args "-no-remote -profile /sdcard/tests/profile --marionette about:blank" --es env3 MOZ_HIDE_RESULTS_TABLE=1 --es env2 R_LOG_VERBOSE=1 --es env1 MOZ_WEBRENDER=0 --es env0 MOZ_CRASHREPORTER=1 --es env7 MOZ_CRASHREPORTER_SHUTDOWN=1 --es env6 MOZ_IN_AUTOMATION=1 --es env5 MOZ_LOG=signaling:3,mtransport:4,DataChannel:4,jsep:4 --es env4 STYLO_THREADS=4 --ez use_multiprocess True --es env12 R_LOG_LEVEL=6 --es env11 MOZ_PROCESS_LOG=/tmp/tmpwSRlk9pidlog --es env10 MOZ_CRASHREPORTER_NO_REPORT=1
[task 2019-09-07T09:11:10.418Z] 09:11:10 INFO - Starting runner
[task 2019-09-07T09:11:10.533Z] 09:11:10 INFO - TEST-START | /service-workers/service-worker/controller-on-load.https.html
[task 2019-09-07T09:11:10.550Z] 09:11:10 INFO - Setting pref dom.serviceWorkers.enabled (true)
[task 2019-09-07T09:11:10.570Z] 09:11:10 INFO - Setting pref javascript.options.streams (true)
[task 2019-09-07T09:11:11.285Z] 09:11:11 INFO - .
[task 2019-09-07T09:11:11.285Z] 09:11:11 INFO - TEST-OK | /service-workers/service-worker/controller-on-load.https.html | took 749ms

Flags: needinfo?(jkt)
Pushed by jkingston@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3af4309ffce7 Remove http override and add appcache pref r=baku

Redirecting to Jonathan. :-)

Flags: needinfo?(ehsan)
Pushed by jkingston@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f3c1becf9396 Remove http override and add appcache pref r=baku

Backed out changeset f3c1becf9396 (bug 1237782) for browser-chrome failures at dom/tests/mochitest/ajax/offline/browser_disableAppcache.js

Backout: https://hg.mozilla.org/integration/autoland/rev/1f082ffd84eaec472a261d99aa198f146b66e2a0

Failure push: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=f3c1becf9396146f31a85fc3ac12206169cf6368

Failure log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=268645542&repo=autoland&lineNumber=3707

[task 2019-09-26T19:48:52.096Z] 19:48:52 INFO - TEST-START | dom/tests/mochitest/ajax/offline/browser_disableAppcache.js
[task 2019-09-26T19:48:53.512Z] 19:48:53 INFO - TEST-INFO | started process screentopng
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - TEST-INFO | screentopng: exit 0
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - Buffered messages logged at 19:48:52
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - Entering test bound test_pref_removes_api
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - Buffered messages logged at 19:48:53
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - Console message: [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "http://example.com/browser/dom/tests/mochitest/ajax/offline/file_simpleManifest.html" line: 0}]
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - Buffered messages finished
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - TEST-UNEXPECTED-FAIL | dom/tests/mochitest/ajax/offline/browser_disableAppcache.js | Appcache is enabled - "no" == "yes" -
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - Stack trace:
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - resource://testing-common/content-task.js line 62 > eval:null:5
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - resource://testing-common/content-task.js:null:63
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - Not taking screenshot here: see the one that was previously logged
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - TEST-UNEXPECTED-FAIL | dom/tests/mochitest/ajax/offline/browser_disableAppcache.js | OfflineResourceList is enabled - "no" == "yes" -
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - Stack trace:
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - resource://testing-common/content-task.js line 62 > eval:null:6
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - resource://testing-common/content-task.js:null:63
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - Leaving test bound test_pref_removes_api
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - GECKO(2850) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - GECKO(2850) | MEMORY STAT heapAllocated not supported in this build configuration.
[task 2019-09-26T19:48:53.999Z] 19:48:53 INFO - GECKO(2850) | MEMORY STAT | vsize 20974966MB | residentFast 1061MB

Assignee: nobody → jkt
Status: NEW → ASSIGNED
Flags: needinfo?(jkt)
Pushed by jkingston@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d52a0108ed8e Remove http override and add appcache pref r=baku

https://hg.mozilla.org/mozilla-central/rev/d52a0108ed8e

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox71: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

(AFAICT from the landed patch, we haven't removed support on release, so updating the summary to clarify that)

Summary: Remove support for appcache → Remove support for appcache on nightly and early beta

Technically we have also just removed storage for now, not support for the API.

Summary: Remove support for appcache on nightly and early beta → Remove support for appcache storage in Nightly

Sorry collision, I was just updating the bug name :')

Summary: Remove support for appcache storage in Nightly → Remove support for appcache storage in Nightly and early beta

The original purpose of this bug was to remove all the appcache related code once we decide to remove it. Is there such a bug? If not, can you please file one (same component - Core:net/cache)? Thanks.

Blocks: 1584984
Regressions: 1585582

Can you test if backing out just the pref change makes the same improvement?
That would be a lot less to then fix to put back in. I'm also still working on a fix for the regression.

Flags: needinfo?(fstrugariu)
Attachment #9099510 - Attachment is obsolete: true

:jkt sorry for this... just noticed it... It was a local change and test that was pushed by mistake to Phabricator.

Flags: needinfo?(fstrugariu)

Documented — because this isn't currently enabled in release, I've added a note to our Experimental Features page: https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features#DOM

Let me know if this looks OK. Thanks!

Keywords: dev-doc-needed → dev-doc-complete
Blocks: 1619673
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: