i have also a question about global variables in service worker. 

i have a global variable A (object). 

first time service worker is executed it create this object.

the second time page is execute it might find A valued , not null. 

What is the best thing for doing it?

Will take a look.

You shouldn't use global variables in service worker to keep state. The worker can be destroyed at any time in between events.

I cannot reproduce the error: https://mattto.github.io/sw/test/claim-first-load/

Both Firefox and Chrome work as expected. I suspect you might be testing .controller before the controllerchange event?

I tested your link. 
In my chrome same problem. 
Sometimes it works , sometimes no. I already saw same behaviour in debug for the problem above in events sequence. 

i press register...
it show registered but controller is null. 

What version of Chrome is this? Please copy/paste from chrome://version.

in firefox version 45 or 46 there are a lot of bugs (globals vars is not working, passing to version 48 it works correctly for global vars).

The same page works in firefox. 

I have now also another problem to solve. 
I dont know how understand service worker is terminated or not active. 
It seams very strange a "thread like" has not a event for understanding if it is stopping 

Please indicate the version of Chrome, not Firefox.

Yes, there's no "stopping" signal. The worker should assume it can be stopped at any time in between events.

Google Chrome	48.0.2564.109 (Build ufficiale) (a 64 bit)
Revisione	dee993990fa912f87e4d1eb5822d408be4896ea5-refs/branch-heads/2564@{#684}
Sistema operativo	Linux 
Blink	537.36 (@dee993990fa912f87e4d1eb5822d408be4896ea5)
JavaScript	V8 4.8.271.19
Flash	21.0.0.216
User-agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36
Riga di comando	/usr/bin/google-chrome-stable --flag-switches-begin --flag-switches-end
Percorso eseguibile	/opt/google/chrome/google-chrome
Percorso profilo	/home/cristian/.config/google-chrome/Default
Varianti	7c1bc906-f55a7974
770a425-f0784d8f
cf5ed6e1-3f4a17df
775ebbd7-3f4a17df
31362330-ca7d8d80
f15c1c09-ca7d8d80
9e5c75f1-fc617d7f
f79cb77b-3d47f4f4
b7786474-64e7d9a
4117e878-84bdb43e
9736de91-ca7d8d80
dbffab5d-ca7d8d80
3ac60855-486e2a9c
f296190c-f5f3fe99
4442aae2-7158671e
ed1d377-e1cc0f14
75f0f0a0-a5822863
e2b18481-4c073154
e7e71889-4ad60575
b39ea213-d1372334
bd368a6b-d2c8e0a4

Thanks. That's pretty old! Current stable is Chrome 51.

Would you mind trying to reproduce with an up-to-date version of Chrome? This may have been an old bug.

i have a websocket. For preventing to close frequently the connection. 
i m trying to use service worker. I work correctly as proxy. 
But i have to test :
1) can it pass from idle to active if websocket connection receive a event?
2) how can i close the socket when service is stopped?
3) i m thinking to monitoring inside the active clients. When it reach the clients count to 0 .... send socket closing

i tried to  notify a websocket event using firefox to chrome client when service worker is stopped.

It doesnt works. It doesnt wake up. 

Sorry I think I need more details to understand, but it's off-topic for this bug tracker. Please consider using Stack Overflow with the service-worker tag. 

Regarding this bug about controller being null, please let me know if you see the bug in Chrome 51 or higher.

> in firefox version 45 or 46 there are a lot of bugs (globals vars is not working, passing to version 48 it works correctly for global vars).

Happy to field firefox bug reports over in:

  https://bugzilla.mozilla.org/enter_bug.cgi?format=guided#h=dupes|Core|DOM%3A%20Service%20Workers

In general, though, you should not rely on global variables in a service worker because its totally up to the browser when the service worker is killed and restarted.

> i tried to  notify a websocket event using firefox to chrome client when service worker is stopped.

WebSockets are not intercepted by service workers, so you will not get a FetchEvent for them.

Generally we have designed the system so you cannot force your service worker to stay alive over long periods.  This is intentional to avoid abuse by bad actors on the web.  If you want a worker that has an exact lifetime you should use a dedicated Worker or SharedWorker.  You can then communicate state via IDB or Cache API.

Websocket is asynchronous object as Push notification Object. So it is not necessary service worker stays alive along as it is not necessary now for PushManagegment. 
Same problem another developer could tell you about event sent messages. 
In general we have now powerfull asynchronous ways but we can 't  use them because service worker offer just Push Manager that follows a model completely not related to new http abilities. 
Shared worker has the life of the shared domain navigation, but if i leave a specific domain i could desire to receive a notification to go again in this site. So shared worker don't satisfy all the possible needs. 
A web worker has the life of the page, so it is not for this use. 
In addition websocket is not a serializable object , so i can't save it in the cache for restoring it in a following request. 





 

I wasn't able to repro this. Please reopen if you can on a version of Chrome >= 51.