Service Worker fetch requests during 'install' phase block fetch requests from main thread
Categories
(Core :: DOM: Service Workers, defect, P3)
Tracking
()
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).
Reporter | ||
Comment 1•5 years ago
|
||
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).
Reporter | ||
Comment 2•5 years ago
|
||
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.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 3•5 years ago
|
||
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.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Andrew, would this be fixed by our new SW implementation?
Comment 5•5 years ago
|
||
302 asuth
Comment 6•5 years ago
|
||
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.
Comment 7•5 years ago
|
||
Adding [geckoview:fenix:p2] whiteboard tag so we track this issue for Fenix PWA support.
Updated•5 years ago
|
Comment 8•2 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Updated•2 years ago
|
Description
•