Closed Bug 1078808 Opened 10 years ago Closed 9 years ago

UI for installed Service Workers

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: overholt, Unassigned)

References

Details

We should do something to show the user what Service Workers have been installed in their profile.  dougt threw about:addons under services out as a potential place.
Blocks: ServiceWorkers
Component: DOM → General
Product: Core → Firefox
Not just show which are installed but allow the user to manage them by uninstalling them (and possibly also disabling without removing, like add-ons?).

Doug and I thought about the "Services" tab because 1) that's a perfect term for them, and 2) the social services already can have a worker which is somewhat like a ServiceWorker. But if the UI affordances end up being different we certainly don't mind having another tab just for ServiceWorkers.
Note that service workers must be cleared together with cookies. Should we have a separate bug for that as that's kind of vital. Otherwise we are shipping a privacy issue.
(In reply to Anne (:annevk) from comment #2)
> Note that service workers must be cleared together with cookies. Should we
> have a separate bug for that as that's kind of vital. Otherwise we are
> shipping a privacy issue.

Filed bug 1080109 and bug 1080110.
I am marking this for v2, but the more privacy centric bugs filed by ehsan in comment 3 as v1. Please comment if this is needed before we ship v1.
Blocks: ServiceWorkers-B2G
No longer blocks: ServiceWorkers
That seems fine. We need to get much better about permission and storage UI, but shipping service workers is more important.
Can somebody point me to information on how service worker information is stored in the profile?  I can take a look at what it would take to include it in the services tab in about:addons.
Shane, the bug that saves data hasn't landed yet (Bug 984050), the records are stored in profiledir/serviceworker.txt as tuples https://bugzilla.mozilla.org/attachment.cgi?id=8562198&action=diff#a/dom/workers/ServiceWorkerRegistrarTypes.ipdlh_sec2

During runtime it is better to query nsIServiceWorkerManager. Happy to add getter utilities to this class as required.
See Also: → 1133601
So I actually think we should not have dedicated UI for service workers themselves. The high-level UI bit should be about storage. 

Perhaps we should let users dive into that and let them decide between service workers, caches (both HTTP and API), localStorage, IDB, cookies, etc. or perhaps we should just offer clearing them all in one go.

It seems far too technical to expose service workers as a thing to end users whereas they will not be able to distinguish them from cookies or cache entries.
At this point I was going to clear SWs when cookies are cleared in the two dependent bugs.
Depends on: 1080109, 1080110
I have thought about this.  ISTM that mixing different types of entries under the same tab could be a bit weird.  e.g. x.com has a socialapi service and the user activates it.  x.com also has a service worker, and the user activates that.  Or, x.com has a socialapi service that instantiates a service worker (I do eventually want to replace the frameworker with a service worker).  There would be two entries under services for x.com.  I suppose they can have different names, but I think we should get UX input.  

Technically it is doable without too much hackery.  We'd create an Addon Wrapper (needed by the addon manager) for service workers and have that tab show two types of addons, the services and the service-workers.
It seems like we won't expose this to the user after all.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
To follow up to comment 8, I now think it should all be called "storage" and we should not have granularity on a per-feature basis. If there is to be granularity we need to let the site be responsible for that per

  https://wiki.whatwg.org/wiki/Storage

or something similar. Exposing details such as IDB, localStorage, or service workers to end users is far too technical.

Bug 1147820 is about fixing storage.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.