New issue
Advanced search Search tips

Issue 707238 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

navigator.serviceworker fails to fire controllerchange event

Reported by davmil...@gmail.com, Mar 31 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36

Steps to reproduce the problem:
1. Open a page with an active service worker that is about to be replaced.
2. The page detects a new service worker and begins to install it.
3. Have the application message the service worker to let it know it should skipWaiting.
4. Service worker should skipWaiting.

What is the expected behavior?
The service worker, upon skipping waiting, should become active, and navigator.serviceworker should fire controllerchange.

What went wrong?
The event controllerchange was not fired, despite dev tools showing that the new service worker had indeed skipped waiting and taken control.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 57.0.2987.110  Channel: stable
OS Version: Fedora 25
Flash Version: unsure

The code I had initially written when I discovered the problem is at https://github.com/davmillar/DavesMapper/commit/a1cc1431f724fecbfacf631b1b9d12498f976351

Additionally, Jake Archibald made a reduced test case to help me work through the issue, and it is at https://cdn.rawgit.com/jakearchibald/8e90f381ebef27686971863cde1d3e3b/raw/188cf791d5d67b7fad68a25eaaf1653dd36a94fe/

Both cases failed to fire controllerchange at first. The issue was resolved after restarting my instance of Chrome using chrome:restart, and listeners were able to detect the fired event in both cases after restarting
 

Comment 1 by falken@chromium.org, Mar 31 2017

Thanks for the report (I was also following along on Twitter). After restarting the browser, could you ever reproduce the problem?

Comment 2 by davmil...@gmail.com, Mar 31 2017

The problem appeared on two additional machines, same OS and version as the first but different hardware. A coworker and I reproduced it using the simplified test case in the original ticket.

My coworker made a weird discovery: It initially did not fire controllerchange, but after disabling AdBlock, the page reloaded and the event fired. Then, after doing 'Empty Cache and Hard Reload', the event did not fire. Following that with a regular refresh, the event started firing again. This seems to be reproducible consistently.

Comment 3 by falken@chromium.org, Mar 31 2017

If possible, can you console.log(navigator.serviceWorker.controller) before calling register()? I wonder if somehow Empty Cache and Hard Reload and similar things is creating a situation where the page does not have a controller in the first place.

Comment 4 by davmil...@gmail.com, Mar 31 2017

OK, I tried using the simple test case page and did the following:

1. Unregistered the SW using dev tools.
2. Entered navigator.serviceWorker.controller in the console, got null.
3. Used the button to register SW 1. No controllerchange event.
4. Entered navigator.serviceWorker.controller in the console, got null.
5. Used the button to register SW 2. No controllerchange event.
6. Entered navigator.serviceWorker.controller in the console, got null.

I tried hard refreshing, got the same results.

I tried regular refreshing, and the controllerchange events fired and the console showed the expected controllers.
hardrefresh.png
100 KB View Download
regularrefresh.png
143 KB View Download

Comment 5 by davmil...@gmail.com, Mar 31 2017

I just tried it in a fresh install of Chrome 57.0.2987.133 on a Windows 7 VM and got the same results as in Comment 4 above. Also, the initial pageload behaved the same as a 'clear cache and hard refresh' test.

From what Jake mentioned on Twitter, after a clear/hard refresh the page doesn't use the SW. So it seems if there's no initial SW controlling the page, the page will never have controller change events no matter how many times a SW is registered and calls skipWaiting().

Comment 6 by davmil...@gmail.com, Mar 31 2017

Just to see if it was a new misbehavior or pre-existing, I tried it on a laptop with Chrome 51.0.2704.106 on Windows 7 and it behaves the same way. Not sure if these are useful data points or not.
Cc: jakearchibald@chromium.org
>  So it seems if there's no initial SW controlling the page, the page will never have controller change events

Yep this is actually expected behavior. For SW to control a page that is initially uncontrolled, it needs to call claim(). 
Labels: Needs-Triage-M57
Labels: -Needs-Triage-M57 TE-NeedsTriageHelp
Labels: -TE-NeedsTriageHelp
Status: WontFix (was: Unconfirmed)
I think this is expected behavior in that a page without a controller should not get controller if claim() isn't used.

Please open a new bug if you expected the page to have a controller in the first place.

Sign in to add a comment