1181390 - fire install and activate events on service worker

Status: RESOLVED WONTFIX

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

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Once a new package has been downloaded, we go through the normal ServiceWorker update cycle. I.e. Gecko fire both "install" and "activate" events on the ServiceWorker. This will happen any time that a package is updated, even if the contents of the ServiceWorker script hasn't changed.

Comment 1

[Dimi Lee [:dimi]]

I will take it first because I am working on NSec. Since I am a freshman of SW, please feel free to give me any advise/suggestion about how to handle this issue, thanks!

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

Again, I have concerns about mixing this signed package complexity in with the service worker code.  Can this be layered on top of the service worker API instead of tightly coupling the two?

Comment 3

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Ben Kelly [:bkelly] from comment #2)
> Again, I have concerns about mixing this signed package complexity in with
> the service worker code.  Can this be layered on top of the service worker
> API instead of tightly coupling the two?

Definitely open to suggestions here.

Comment 4

[Dimi Lee [:dimi]]

Once package is update, we might need to consider following cases when fire sw event
1. sw script is changed
2. only resources are changed, sw isn't changed
3. script/document that load sw script is changed

And would it possible that we have a common API inside service worker to handle all these cases because the component triggers package updating might not aware of this. Or should we build a layer top of sw to reduce sw complexity?

Comment 5

[Dimi Lee [:dimi]]

Comment on the meeting:
For pinned package, we need to find a way to know if there are any service workers running in this package.

Comment 6

[Dimi Lee [:dimi]]

(In reply to Dimi Lee[:dimi][:dlee] from comment #4)
> Once package is update, we might need to consider following cases when fire
> sw event
> 1. sw script is changed
> 2. only resources are changed, sw isn't changed
> 3. script/document that load sw script is changed
> 
> And would it possible that we have a common API inside service worker to
> handle all these cases because the component triggers package updating might
> not aware of this. Or should we build a layer top of sw to reduce sw
> complexity?
Conclusion in the meeting:
Only need to fire event when sw script is changed

Comment 7

[Dimi Lee [:dimi]]

(In reply to Dimi Lee[:dimi][:dlee] from comment #6)
> (In reply to Dimi Lee[:dimi][:dlee] from comment #4)
> Conclusion in the meeting:
> Only need to fire event when sw script is changed
Forget to comment, this is for non-pinned case.

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

I believe for the pinned case we said we would unregister any existing service workers, swap the pinned package, and then try to register the same service workers again.  If the service workers scripts moved or something, then the register will fail and it won't get registered until the app is next opened.

Comment 9

[Ethan Tseng [:ethan]]

The new security model project was suspended.
We had discussed the idea of NSEC v2, which seems we are unlikely to use signed package format.
So there is no reason to keep working on this bug.

p.s. We don't have plan on NSEC v2 either.