Status

()

defect
P3
normal
3 years ago
5 months ago

People

(Reporter: Ehsan, Unassigned)

Tracking

(Blocks 11 bugs, {dev-doc-needed, site-compat})

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s-)

Details

(Whiteboard: [necko-backlog])

(Reporter)

Description

3 years ago
This is a tracker for the work required to stop supporting appcache.
(Reporter)

Updated

3 years ago
Depends on: 1237783
What is your timeline for this?  It seems exceptionally early to consider doing it.
(Reporter)

Comment 3

3 years ago
(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.

Comment 4

3 years ago
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.

Comment 5

3 years ago
> 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.

Comment 6

3 years ago
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.
(Reporter)

Comment 8

3 years ago
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

Comment 9

3 years ago
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.

Comment 10

3 years ago
> 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.
(Reporter)

Comment 11

3 years ago
(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
Duplicate of this bug: 814330
Duplicate of this bug: 445733
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: --- → ?

Updated

3 years ago
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!

Comment 22

3 years ago
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.

Comment 29

3 years ago
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).

Comment 31

3 years ago
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.

Comment 33

3 years ago
(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.

Comment 34

3 years ago
(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)

Comment 38

3 years ago
(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

Comment 39

3 years ago
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.

Comment 43

3 years ago
(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.

Comment 44

3 years ago
https://github.com/kenchris/jakecache is uses ServiceWorkers to polyfill appcache, for anyone affected & looking for a quick fix.

Comment 45

3 years ago
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.

Comment 47

3 years ago
(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.
Comment hidden (off-topic)
Comment hidden (off-topic)

Updated

3 years ago
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

Updated

2 years ago
Blocks: 1350544

Updated

2 years ago
Blocks: 1354175

Updated

2 years ago
Blocks: 1014145

Updated

2 years ago
Blocks: 740124
You need to log in before you can comment on or make changes to this bug.