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

Mass move to the new application panel component.

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

(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.

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!

> - 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?

(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!

(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.

(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

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.

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.

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.

> 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).