Open Bug 1531511 Opened 5 years ago Updated 2 years ago

Service Worker fetch requests during 'install' phase block fetch requests from main thread

Categories

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

65 Branch
defect

Tracking

()

Tracking Status
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- affected

People

(Reporter: nolan, Unassigned)

References

Details

(Whiteboard: [geckoview:fenix:p2])

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

In my app Pinafore (https://pinafore.social), anytime a new Service Worker is installing, fetch() requests for regular resources (e.g. JS) are blocked, even though those resources are cached. This causes the nav buttons to not work until the 'install' phase is complete.

Steps to reproduce:

  • git clone https://github.com/nolanlawson/pinafore.git
  • cd pinafore
  • yarn && yarn build && yarn start
  • Open the site in Firefox for Android to install the Service Worker
  • Add the site to the home screen
  • Close Firefox
  • Change any JavaScript file in src/routes (to trigger a Service Worker update)
  • yarn build && yarn start
  • Open the PWA in Firefox for Android

Actual results:

The top nav buttons are unusable until you see the message "Update available, reload to update."

Expected results:

The nav buttons should be interactible, because the fetch requests from the main thread (especially if they are for resources already cached by the Service Worker) should not be blocked by Service Worker install requests.

I do not observe this behavior in Chromium for Android. I'm using Firefox 65.0 on Android 8.1.0 without Google Play Services (LineageOS).

Note this may be difficult to repro locally unless you have some kind of network throttling enabled. The server I use in production is provided by Zeit Now (https://zeit.co/now).

Upon further inspection, it looks like Chrome also considers JavaScript and CSS requests originating from caches.addAll() to be high-priority. After reading through https://github.com/w3c/ServiceWorker/issues/1137, it appears that we need Priority Hints in order to make this a reality, since we cannot assume that requests originating from the Service Worker's install phase are low-priority: https://github.com/WICG/priority-hints

Closing this issue.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Reopening because Ben Kelly says:

"I believe Firefox also still sends all those network requests from the SW through the main thread. That can also interfere with main thread work, but is separate from the priority mechanism." (https://toot.cafe/@wanderview/101684346892078182)

So this may still be a valid bug, and it would explain why I seem to only see this behavior in Firefox, not Chrome.

Whiteboard: [geckoview]

Andrew, would this be fixed by our new SW implementation?

Flags: needinfo?(overholt)

302 asuth

Component: Web Apps → DOM: Service Workers
Flags: needinfo?(overholt) → needinfo?(bugmail)
Product: Firefox for Android → Core
Version: Firefox 65 → 65 Branch

The new SW implementation does not change how fetch works, however :smaug landed a fix to our prioritization of network requests on the main thread from workers in Bug 1522316 in Firefox 67 which should dramatically improve what's happening in this scenario. (Thank you, :smaug!)

The general family of bugs related to fetch needing to happen via the main thread and resulting in contention is:

  • Bug 1330826 is about us having to involve the main thread for fetch/XHR.
  • Bug 1351231 proposes the fix of having fetch requests go over PBackground.

We had a discussion with the Necko team about the right strategy for this and they have committed to making asyncOpen and OnStart/OnStop off-the-main-thread which is likely how bug 1330826 will be addressed. Bug 1532253 is the most recent progress to this end.

Flags: needinfo?(bugmail)

Adding [geckoview:fenix:p2] whiteboard tag so we track this issue for Fenix PWA support.

See Also: → 1522316, 1330826
Whiteboard: [geckoview] → [geckoview:fenix:p2]
Priority: -- → P3

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.