Closed Bug 1547023 (ServiceWorkers-ESR) Opened 6 years ago Closed 4 years ago

[meta] Enable ServiceWorkers on ESR

Categories

(Core :: DOM: Service Workers, task, P3)

Product:
Core
Component:
DOM: Service Workers
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
relnote-firefox --- 78+
firefox-esr68 --- unaffected
firefox-esr78 --- fixed
firefox77 --- unaffected
firefox78 --- unaffected
firefox79 --- unaffected

People

(Reporter: asuth, Unassigned)

References

Details

(Keywords: dev-doc-complete, meta)

We've been disabling ServiceWorkers on ESR releases because of the long-running ServiceWorker e10s overhaul because:

  • The e10s overhaul seemed to make uplifts to ESR infeasible.
  • We were concerned about diverging implementations posing a health problem to the web, as ESR would see different ServiceWorker semantics from what we ship.

As we're now very close to landing the e10s ServiceWorkers overhaul, there are also some other potential issues to be concerned about:

  • SPECTRE attacks in a pre-fission implementation where ServiceWorkers enable long-running background execution in any content process without origin restrictions.
  • Abuse of background execution capabilities, potentially triggered by push, with limited user visibility into CPU usage and limited mitigations capabilities.

While these are also current potential issues against trunk, we are more able to effectively mitigate and iterate on these problems and it's not clear such fixes would be something that could be uplifted to ESR.

It's also not immediately clear what benefit a frozen-in-time ServiceWorkers implementation would serve on ESR. Currently, the value ServiceWorkers provide that transcends progressive enhancement is offline functionality and push notification functionality. Anecdotal analysis indicates that most use is for push notifications, functionality that appears very popular with websites but less popular with users.

Note that I'm primarily filing this bug for tracking and to consolidate discussion. My above comments inform my own perspective on the issue and I think they should be considered in any decision-making process, but are not the only issues to be considered and I am not the decision-maker.

Type: defect → enhancement
Alias: ServiceWorkers-ESR
Type: enhancement → task
Priority: -- → P3

We deliver HTML5 mobile applications to several customers - there are about 6-8K of end users in total, the number is still growing. They all use Firefox ESR release as client for our apps. The curcial feature of our app is the ability to deliver the content in offline mode. The app itself are cached via applicationCache or ServiceWorkers and the business data is stored in the browser's database (IndexedDB). After release of Firefox 44 the applicationCache has been declared as deprecated (see bug 1204581). After that we considered and switched the app caching to service workers. The usage of the service workers with Firefox ESR actually requires manual configuration effort to enable it. This erfort causes sometimes a big impact on the customer site due to existing infrastructure and software distribution.

If Mozilla deprecates the Offline Application Cache feature there should be definitely an alternative option available for developers to create offline web applications WITHOUT changing configuration files in Firefox. Please set the parameter dom.serviceWorkers.enabled to true in the next ESR release - as it is in Chrome or Safari.

So what’s the plan for Firefox 68? I haven’t seen a bug to disable Service Workers in 68 ESR yet, but if the decision is no-go, it has to be done now since it’s in the mid-Beta cycle. I’ll post a document to FxSiteCompat.com as always.

Flags: needinfo?(bugmail)
See Also: → 1557154
See Also: → 1557565

I've filed bug 1557565 to disable ServiceWorkers on 68 ESR but not the Fennec 68 ESR. Beginning series of try pushes soon.

Flags: needinfo?(bugmail)

:asuth, this is a meta bug without any dependencies to be worked on. Still the subject and comments seem somewhat meaningful. Is there any work to plan here?

Flags: needinfo?(bugmail)

I think we can mark this fixed once sw-e10s rides the trains to release, as by default ServiceWorkers would ride the ESR train if they hit release. This bug is mainly useful right now for those who want to know "will I see ServiceWorkers for sure on the next ESR?". The answer right now is "very probably", but we shouldn't mark it fixed until it's a given.

Flags: needinfo?(bugmail)

Tentative plan is that ServiceWorkers will ship enabled on 78 ESR.

78 is coming in 2 weeks. What’s the final decision here?

Flags: needinfo?(bugmail)

🚢🚢🚢🚢🚢🚢🚢
Ship on ESR 78!
🚢🚢🚢🚢🚢🚢🚢

Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox-esr78: affected → fixed
tracking-firefox-esr78: ? → ---
Flags: needinfo?(bugmail)
Resolution: --- → FIXED

Release Note Request (optional, but appreciated)
[Why is this notable]: Service Worker and Push APIs have been disabled in Firefox 45, 52, 60, 68 ESRs. Now enterprise apps can utilize the offline support or push notifications in ESR.
[Affects Firefox for Android]: No
[Suggested wording]: Service Worker and Push APIs have been enabled in Firefox 78 ESR.
[Links (documentation, blog post, etc)]:

relnote-firefox: --- → ?
You need to log in before you can comment on or make changes to this bug.