[workbox-window] Waiting event does not trigger sometimes.

[azizhk]

Library Affected: workbox-window
workbox-sw, workbox-build, etc.

Browser & Platform: Google Chrome Version 75.0.3770.142

Issue or Feature Request Description:
Your request here. Issue
Steps to reproduce (sometimes)

1. Open tab and register service worker

const wb = new Workbox('/sw.js')
this.wb = wb
this.registration = await wb.register()
wb.addEventListener('waiting', this.onSWWaiting)

2. Keep tab open for an hour, lock screen, switch to another tab.
3. Build your service worker again, open your website in a new tab.
4. In the new tab it shows that a new version is available, but it does not trigger in the long open tab.

I have the following Chrome extensions, I don't think any of Chrome apps are suspending the tab. (The js in the long running tab is still running)

[azizhk]

Reproducing Repo: https://github.com/azizhk/next-workbox/
Can be deployed on Netlify. (Demo: https://mystifying-almeida-8880f8.netlify.com/)
So you can fork and deploy, open a tab, the run deploy again.

Netlify Commands:

• Build Command: yarn build
• Publish Directory: out

[jeffposnick]

CC: @philipwalton to confirm.

This sounds to me like the scenario described at https://developers.google.com/web/tools/workbox/modules/workbox-window#when_an_unexpected_version_of_the_service_worker_is_found

There's an externalwaiting event that workbox-window fires when the updated service worker originated from a different tab.

Does that address your issue?

[azizhk]

Yup, I guess this must be it.
Is there some heuristic which determines whether waiting or externalwaiting gets triggered.
Because I had waiting triggered on me for some cases even when I installed the SW in a different tab.

[philipwalton]

Yeah, the heuristic is here. You can see the comments in the code:

workbox/packages/workbox-window/src/Workbox.ts

Lines 343 to 374 in 4e770a6

	// If the script URL passed to `navigator.serviceWorker.register()` is
	// different from the current controlling SW's script URL, we know any
	// successful registration calls will trigger an `updatefound` event.
	// But if the registered script URL is the same as the current controlling
	// SW's script URL, we'll only get an `updatefound` event if the file
	// changed since it was last registered. This can be a problem if the user
	// opens up the same page in a different tab, and that page registers
	// a SW that triggers an update. It's a problem because this page has no
	// good way of knowing whether the `updatefound` event came from the SW
	// script it registered or from a registration attempt made by a newer
	// version of the page running in another tab.
	// To minimize the possibility of a false positive, we use the logic here:
	let updateLikelyTriggeredExternally =
	// Since we enforce only calling `register()` once, and since we don't
	// add the `updatefound` event listener until the `register()` call, if
	// `_updateFoundCount` is > 0 then it means this method has already
	// been called, thus this SW must be external
	this._updateFoundCount > 0 ||
	// If the script URL of the installing SW is different from this
	// instance's script URL, we know it's definitely not from our
	// registration.
	!urlsMatch(installingSW.scriptURL, this._scriptURL) ||
	// If all of the above are false, then we use a time-based heuristic:
	// Any `updatefound` event that occurs long after our registration is
	// assumed to be external.
	(performance.now() >
	this._registrationTime + REGISTRATION_TIMEOUT_DURATION) ?
	// If any of the above are not true, we assume the update was
	// triggered by this instance.
	true : false;

If you were able to deploy a new version of the service worker in less than a minute, you'd get a false positive on the heuristic.