fire install and activate events on service worker

RESOLVED WONTFIX

Status

()

Core
DOM: Service Workers
P2
normal
RESOLVED WONTFIX
3 years ago
2 years ago

People

(Reporter: pauljt, Assigned: dimi)

Tracking

unspecified
FxOS-S8 (02Oct)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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.
(Assignee)

Comment 1

3 years ago
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!
Assignee: nobody → dlee
Status: NEW → ASSIGNED

Comment 2

3 years ago
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?
Flags: needinfo?(ptheriault)
(Reporter)

Comment 3

3 years ago
(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.
Flags: needinfo?(ptheriault)
(Reporter)

Updated

2 years ago
Target Milestone: --- → FxOS-S8 (02Oct)
(Reporter)

Updated

2 years ago
Priority: -- → P1
(Reporter)

Updated

2 years ago
Priority: P1 → P2
(Assignee)

Comment 4

2 years ago
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?
(Assignee)

Comment 5

2 years ago
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.
(Assignee)

Comment 6

2 years ago
(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
(Assignee)

Comment 7

2 years ago
(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

2 years ago
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.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.