1220747 - [meta] Migrate about:serviceworkers to about:debugging.

Status: RESOLVED FIXED

(DevTools :: about:debugging, defect, P3)

Description

[Jan Keromnes [:janx]]

We would like to deprecate the "about:serviceworkers" page.

Before we do that, all its existing "about:serviceworkers" features should be supported by "about:debugging".

Any new "about:serviceworkers" feature requests should be filed against / moved to "about:debugging".

Comment 1

[Andrea Marchesini [:baku]]

Currently in about:serviceworkers we support:

1. the list of registered SWs and for each we show: Scope/ScriptSpec/CurrentWorkerURL/ActiveCacheName (not particularly useful)
2. the push end point.
3. the possibility to unregister a SW.
4. the possibility to update the SW.

What we would like to have is:

1. state of the SW: installing/waiting/active.
2. start/stop the SW

I guess these are the main 2 features we would like to see in about:debugging.

Comment 2

[Andrew Overholt [:overholt]]

There are some Push requests, too, which I've moved to the about:debugging component.

Comment 3

[Jan Keromnes [:janx]]

Thanks for your help, Andrea and Andrew!

Comment 4

[Jan Keromnes [:janx]]

Hi Helen!

I have trouble picturing how best to display the list of Service Workers in about:debugging, especially with all the additional details and buttons that we'd like to add for this bug. Could you please help me out with a sketch?

Here is the complete list of what we'd like to show for a Service Worker:
- Scope, e.g. "Scope: https://mdn.github.io/sw-test/"
- Script, e.g. "Script: https://mdn.github.io/sw-test/sw.js"
- Install status, e.g. "installing", "waiting" or "active"
- Running status, e.g. "running" or "stopped"
- Push status (for "Push" workers only), e.g. "connected" or "disconnected"
- "Unregister" button
- "Start/Stop" button, e.g. "Stop" if the worker is running or "Start" if it's not)
- "Push" button (for "Push" worker only, if the worker is running)
- "Debug" button

Caveats:

1. We were originally thinking of hiding the "Running status" and "Start/Stop" buttons to the user (normally you can't "Debug" a Service Worker if it's not "running", but we were thinking about making the "Debug" button automatically start the worker if it's stopped). Now, I'm not sure anymore, because Andrea specifically asked us to show "Running status" in comment 1. Andrea, do you think developers will care about "Running status" and "Start/Stop" buttons, or can we abstract that from UI?

2. Some of the listed things are registration-level (e.g. "Scope", "Unregister"...) and some are worker-level (e.g. "Debug", "Start/Stop"). Normally "registration" and "worker" can be considered to be the same thing (most developers do that), but there is a situation where a registration can have two workers (one with install status "active" and one with "waiting"). It's a rare transition case, so I thought it's not worth it to create a separated hierarchy with a "registration" and some "workers" underneath it, but if we just show a list of Service Workers as described above, sometimes two entries will correspond to the same "registration", which means that their "Scope" will be the same, the "Unregister" button on each entry will make both entries disappear, etc. Not a big issue I think, but Chrome shows a registration > worker hierarchy.

I will upload some screenshots to show you how similar existing tools display Service Worker details and controls.

Comment 5

[Jan Keromnes [:janx]]

Attachment: aboutdebugging.png

Today, about:debugging only shows "Script URL" and the "Debug" button (please disregard the "Push" button, that's a work in progress).

I don't really know where to add all the other details, status information and buttons without making the UI bloated or confusing.

Comment 6

[Jan Keromnes [:janx]]

Attachment: aboutserviceworkers.png

Today, about:serviceworkers shows more details and controls:
- "Script Spec" = "Script URL".
- I don't really know what "Current Worker URL", "* Cache Name" or "Push Endpoint" are for, but I don't think we need them.
- I don't think we need the "Update" button either (it doesn't seem to do anything in this UI).

Comment 7

[Jan Keromnes [:janx]]

Attachment: chrome-serviceworkerinternals.png

Chrome's serviceworkers-internals page shows even more details and controls (about everything I'd like to show in about:debugging, plus more things we don't need).

It also shows a hierarchy (see 2nd caveat avec "registration" vs "worker" in comment 4). Unindented things are registration-level, and indented things are worker-level. Under the "Active Worker" block, there could be a "Waiting Worker" block, with separate "Stop/Push/Inspect" buttons, but the "Unregister" button wpuld be common to both workers.

Comment 8

[Florian Bender]

Once about:debugging provides everything about:serviceWorkers does, the latter should redirect (or at least point to) the former.

Comment 9

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Jan Keromnes [:janx] (away until January 1st) from comment #4)
> 1. We were originally thinking of hiding the "Running status" and
> "Start/Stop" buttons to the user (normally you can't "Debug" a Service
> Worker if it's not "running", but we were thinking about making the "Debug"
> button automatically start the worker if it's stopped). Now, I'm not sure
> anymore, because Andrea specifically asked us to show "Running status" in
> comment 1. Andrea, do you think developers will care about "Running status"
> and "Start/Stop" buttons, or can we abstract that from UI?
If there's no objection, I think that this would clean up the UI significantly. Having the "debug" button start the worker makes sense; if people are worried that this could be confusing, we could have some sort of flag on the worker line that it's started/stopped.

Comment 10

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: sw-aboutdebugging.jpg

First draft of what I was thinking. It could perhaps toggle on click, or when the user hits the "debug" button. It doesn't necessarily solve the issue of how to visually represent different registration/worker hierarchies, but it's a start I guess?

Comment 11

[Jan Keromnes [:janx]]

Thanks Helen! Your draft looks very useful, and I like the idea of tags.

- Pending Andrea's opinion about showing/hiding the running status of a worker, let's show the status as a trailing tag (yay!)
- Maybe there is no need to visually differentiate between registration/worker-level things, at least for now.
- Toggle on click might be a good idea if we start having too much information, but let's start without a toggle and see where it leads us.

Also, I don't fully picture how the final page should look like according to your draft, but a draft is good enough for this increment. I'll add tags and a few more things and come back to you then.

Comment 12

[Jan Keromnes [:janx]]

Let's opt for showing the status.

Comment 13

[Helen V. Holmes (:helenvholmes) (:✨)]

I can definitely mock up something more formal if it would be helpful, Jan—but if it helps it make it any more clear, I was imagining you'd continue using the same styles from previous versions. If you want to do the increment and ping me for a ui-review, that could work.

Comment 14

[Robin Whittleton]

All the dependencies here have been closed, so I guess this is done?

Comment 15

[:Harald Kirschner :digitarald]

Closing as done as all deps are closed.