Julian Descottes [:jdescottes] Reporter
	Description • 7 years ago

Follow up to Bug 1445197. We should display the UUID of the service worker as a tooltip (when hovering the scope I assume?)

	Patrick Brosset <:pbro>
	Comment 1 • 6 years ago

Mass move to the new application panel component.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 2 • 6 years ago

Is "the UUID of the service worker" the same as the `cacheName` property on `nsIServiceWorkerInfo`?

	Ben Kelly [:bkelly, not reviewing]
	Comment 3 • 6 years ago

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #2)
> Is "the UUID of the service worker" the same as the `cacheName` property on
> `nsIServiceWorkerInfo`?

Yes, I believe so.

	Belén [:ladybenko]
	Comment 4 • 6 years ago

Hi Harald, we were discussing this feature and we have some doubts about how users would interact with this:

- Is this UUID usable somewhere else? (i.e. some api, or logs, etc.) If so, it might make sense to allow users to copy it, and thus making a tooltip unsuitable for this.

- There are occassions in which this UUID might not be available. Should we add an alternate message if the UUID doesn't exist yet? Having a tooltip sometimes appear and sometimes not appearing could be confusing.

- If this UUID is just for identifying unique versions of a worker, then the UUID is probable too long for users to remember (unless we allow the copy & paste).

Thanks!

	:Harald Kirschner :digitarald
	Comment 5 • 6 years ago

> - Is this UUID usable somewhere else? (i.e. some api, or logs, etc.) If so, it might make sense to allow users to copy it, and thus making a tooltip unsuitable for this.

Not afaik, this is only an internal handle.

> - There are occassions in which this UUID might not be available.

Which are those?

> - If this UUID is just for identifying unique versions of a worker, then the UUID is probable too long for users to remember (unless we allow the copy & paste).

The best solution would be showing an incremental version number (per scope); that would mean we keep the SW state internally and increment it when we see a new UID. The risk is resetting that number when devtools is closed and starting from 0 the next time the panel open; but would work well as a best effort. It seems more effort, but would that generally be feasible?

	Belén [:ladybenko]
	Comment 6 • 6 years ago

(In reply to :Harald Kirschner :digitarald from comment #5)
> > - Is this UUID usable somewhere else? (i.e. some api, or logs, etc.) If so, it might make sense to allow users to copy it, and thus making a tooltip unsuitable for this.
> 
> Not afaik, this is only an internal handle.

Alright, thanks!

> 
> > - There are occassions in which this UUID might not be available.
> 
> Which are those?

We are still evaluating these. Ben, is the waiting cache name that appear in `about:serviceworkers` something we could use if the `cacheName` is not available? Thanks!


> > - If this UUID is just for identifying unique versions of a worker, then the UUID is probable too long for users to remember (unless we allow the copy & paste).
> 
> The best solution would be showing an incremental version number (per
> scope); that would mean we keep the SW state internally and increment it
> when we see a new UID. The risk is resetting that number when devtools is
> closed and starting from 0 the next time the panel open; but would work well
> as a best effort. It seems more effort, but would that generally be feasible?

This is similar to what Chrome is showing (they use an incremental integer). Let's create a follow up bug for this, since we need to take persistence into consideration. I created https://bugzilla.mozilla.org/show_bug.cgi?id=1466063 for this.

Thanks!

	Ben Kelly [:bkelly, not reviewing]
	Comment 7 • 6 years ago

(In reply to Belén [:ladybenko] from comment #6)
> > > - There are occassions in which this UUID might not be available.
> > 
> > Which are those?
> 
> We are still evaluating these. Ben, is the waiting cache name that appear in
> `about:serviceworkers` something we could use if the `cacheName` is not
> available? Thanks!

The nsIServiceWorkerInfo.cacheName value is set as soon as the object is created.  So I think it should always be available.

	Julian Descottes [:jdescottes] Reporter
	Comment 8 • 6 years ago

(In reply to Ben Kelly [:bkelly] from comment #7)
> (In reply to Belén [:ladybenko] from comment #6)
> > > > - There are occassions in which this UUID might not be available.
> > > 
> > > Which are those?
> > 
> > We are still evaluating these. Ben, is the waiting cache name that appear in
> > `about:serviceworkers` something we could use if the `cacheName` is not
> > available? Thanks!
> 
> The nsIServiceWorkerInfo.cacheName value is set as soon as the object is
> created.  So I think it should always be available.

A ServiceWorkerRegistration can have an activeWorker or a waitingWorker. 

I think the question can be rephrased as "if activeWorker is null (and therefore activeWorker.cacheName is unavailable, does it make sense to fallback on the waiting worker?".

Cf the code from aboutserviceworkers: https://searchfox.org/mozilla-central/rev/83a923ef7a3b95a516f240a6810c20664b1e0ac9/toolkit/content/aboutServiceWorkers.js#119-122

	Ben Kelly [:bkelly, not reviewing]
	Comment 9 • 6 years ago

I don't understand.  The version or cache number is based on the worker, not the registration.  A registration could have both active and waiting workers, each with their own version numbers.  I think it makes most sense to surface this in the UX.  So the developer could see the version of the active, waiting, and installing workers separately.

If you want to try taking these multiple version numbers and force them into a single registration version, I'm not sure I can help.  This does not really reflect what is going on in the platform, AFAIK.

	Julian Descottes [:jdescottes] Reporter
	Comment 10 • 6 years ago

Same as in about:debugging, right now in the application panel we only show registrations, not workers. That is planned for the next milestone but for now we don't make a clear difference between registration and worker. For now if we have a registration that has both an active and a waiting worker, there is just a single entry in the UI. 

Maybe surfacing this UUID doesn't make sense until we clearly show the workers separately from the registration.

	Ben Kelly [:bkelly, not reviewing]
	Comment 11 • 6 years ago

Could we do something like "<uuid value> (active)" or "<uuid value> (waiting)", etc.

Of course, if there is no active worker, then there should be a very small time period where you could have a waiting worker.  It will immediately try transitioning to active.  So maybe its fine to just show nothing for waiting.

	:Harald Kirschner :digitarald
	Comment 12 • 6 years ago

> Maybe surfacing this UUID doesn't make sense until we clearly show the workers separately from the registration.

Seeing Ben's concern, this sounds right. We should move this into stretch goal 1.1 when we have the registrations list (and updated the PRD).