Application panel: add button to force Update

NEW
Unassigned

Status

enhancement
P2
normal
a year ago
10 months ago

People

(Reporter: jdescottes, Unassigned)

Tracking

(Depends on 1 bug, Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

a year ago
Follow up to Bug 1445197.

The Application panel will show a button to unregister a service worker. We should also have a button to force an update of a service worker. See mockups at https://projects.invisionapp.com/share/ZQGIRLJ2KBU#/screens/287275492_Artboard
(Reporter)

Comment 1

a year ago
I am trying to add an "Update" button in the application panel, that should trigger the update of a service worker registration (ie https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/update).

I tried using the same approach as in about:serviceworkers here, but the update button available there triggers a "soft update" (https://searchfox.org/mozilla-central/source/dom/interfaces/base/nsIServiceWorkerManager.idl#141) which is not followed by a new installation of the service worker. Is there another way to trigger a "real" update on a service worker registration? Or should we add new APIs to ServiceWorkerManager or ServiceWorkerRegistrationInfo?
Flags: needinfo?(bkelly)
(Reporter)

Updated

a year ago
Assignee: nobody → jdescottes
Status: NEW → ASSIGNED
I think we probably need to expose a skipWaiting() on the nsIServiceWorkerInfo.  That would allow devtools to trigger an update and then set the skipWaiting() on the installing worker.  This would then fully activate.  Once the activation completes you could refresh the tab.

Currently skipWaiting() is only available within the ServiceWorkerGlobalScope on the sw thread.
Flags: needinfo?(bkelly)
Mass move to the new application panel component.
Component: Developer Tools → Developer Tools: Application Panel
(Reporter)

Updated

a year ago
Depends on: 1459581, 1450067
(Reporter)

Comment 7

a year ago
I will pick this back up when the blocking bugs have landed, but the current state is that we have:
- new actor method that "simulates" an update by doing a propagateSoftUpdate/attachDebugger/detachDebugger
- new button to trigger the update
- end to end test
(Reporter)

Comment 8

a year ago
Based on your suggestions, I tried to expose skipWaiting in the patch attached here. 

I don't think this is exactly what I need here, because the current issue is that after calling `propagateSoftUpdate`, installation is not triggered. 

I don't necessarily want to force skipWaiting as part of the update anyway, we should rather surface it as a dedicated control, for instance a "skip waiting" button or link displayed only when the current service worker is waiting.

I need an API that would do the exact same as calling "update()" on a service worker registration. Right now doing propagateSoftUpdate then attachDebugger then detachDebugger seems to "emulate" that (except it tries to start the worker even if there was no update). But that is really hacky. Should I try to implement a "propagateUpdate" that would perform the update of the service worker registration?
Flags: needinfo?(bkelly)
You should not be calling propagateSoftUpdate, IMO.  We probably want you to be able to trigger an update similar to what navigations trigger, which is ServiceWorkerRegistrationInfo::MaybeScheduleUpdate().  Of course, that uses a 1 second delay that may not be what you want.

Honestly I think it would be easier to implement all this after the e10s work is complete.  I'm worry you are going to implement something that needs to be re-done shortly.  For example, all the "propagate" stuff is going to go away.

Also, what process are you accessing the nsIServiceWorker* interface is it the parent process?  These interfaces are going to go away in the content processes soon.
Flags: needinfo?(bkelly)
(Reporter)

Comment 10

a year ago
Thanks for the feedback. 

> We probably want you to be able to trigger an update similar to what navigations trigger, 
> which is ServiceWorkerRegistrationInfo::MaybeScheduleUpdate().  Of course, that uses a 1 
> second delay that may not be what you want.

A one second delay is not a big issue for now, we could run with that.

> Honestly I think it would be easier to implement all this after the e10s work is complete.
> I'm worry you are going to implement something that needs to be re-done shortly.  

Sure, let's block this on Bug 1231208 then. I will re-upload cleaned up versions of the UI and test patches, but will leave the actor patch for later.

> For example, all the "propagate" stuff is going to go away.

We already rely on propagate* to unregister service workers for now: 
https://searchfox.org/mozilla-central/rev/da499aac682d0bbda5829327b60a865cbc491611/devtools/server/actors/worker.js#387

That's one spot that needs to be updated when the refactor lands.

> Also, what process are you accessing the nsIServiceWorker* interface is it the parent process?
> These interfaces are going to go away in the content processes soon.

Normally from the parent process, but to start service workers (with attach/detachDebugger), we also broadcast a message to all processes: https://searchfox.org/mozilla-central/rev/da499aac682d0bbda5829327b60a865cbc491611/devtools/server/actors/worker.js#359-367

That will also need to be updated.
(Reporter)

Updated

a year ago

Updated

11 months ago
Product: Firefox → DevTools
(Reporter)

Updated

11 months ago
Priority: P3 → P2
(Reporter)

Comment 11

10 months ago
unassigning since we are not working on this at the moment.
Assignee: jdescottes → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.