Open Bug 1506892 Opened 6 years ago Updated 2 years ago

Add logging to ServiceWorker implementation exposed via about:serviceworkers

Categories

(Core :: DOM: Service Workers, enhancement, P2)

Product:
Core
Component:
DOM: Service Workers
Type:
enhancement

Tracking

()

Status:
ASSIGNED

People

(Reporter: asuth, Assigned: asuth)

References

(Blocks 3 open bugs)

Details

Attachments

(3 files, 8 obsolete files)

WIP: Bug 1506892 - sw_log_p1
(deleted), text/x-phabricator-request
Details
WIP: Bug 1506892 - sw_log_p2
(deleted), text/x-phabricator-request
Details
WIP: Bug 1506892 - sw_log_p3
(deleted), text/x-phabricator-request
Details
We're in agreement to add MOZ_LOG support to our ServiceWorker and Cache API implementations to aid in debugging. We don't expect to get this all done at once, hence this meta bug. Any bug that adds logging or plans to add logging should be made to block this bug. Bugs should ideally be short-lived with any additional logging landing quickly. Any bug that wishes we had this logging should perhaps 'see also' this bug. Good prior art for the initial implementation is IDB's abstractions at https://searchfox.org/mozilla-central/source/dom/indexedDB/ProfilerHelpers.h that covers both profiler markers as well as general MOZ_LOG-ing. Note that its implementation is more complex due to its desire to log rich types (keys, key ranges) that don't trivially stringify on their own. It's okay/desired for most logging to go directly to MOZ_LOG. NB: There's a cool log analyzer tool that can consume the logs that lives at https://github.com/mayhemer/logan that can be augmented to understand the logs we add.
Priority: -- → P3
Depends on: 1517194

I'd classify this as a task as it does not add value to the end-user.

Type: enhancement → task

I'm re-purposing this to cover an in-memory circular-ish log of structured JSON log entries for ServiceWorker related subsystems that can be exposed to about:serviceworkers. The end goal will be to make these available for synchronous logging via the existing MOZ_LOG subsystem as well for CI/automated testing, but the goal is to meet the debugging workflow of:

  1. Someone experiences a problem that may involve ServiceWorkers.
  2. I tell them to reproduce the problem, then go to about:serviceworkers, hit ctrl-f to find the origin in question where we're seeing problems, then either look at the results there or click a "copy" button and then paste that into the bug as an attachment or email the contents to me.
    • A critical point here is that this provides a means of limiting any data provided by the person reproducing the problem to the origin of question. A general concern I have about MOZ_LOG, especially for http logging/etc. is that it captures the entire fire-hose which provides an uncomfortable amount of information. For this specific use case we generally expect the bug to already be discussing a very specific site and so there ideally wouldn't be any additional private data revealed other than what would be present in the URLs for this specific origin.
Assignee: nobody → bugmail
Blocks: 1668743
Status: NEW → ASSIGNED
Type: task → enhancement
No longer depends on: 1517194
Priority: P3 → P2
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1517194, https://bugzilla.mozilla.org/show_bug.cgi?id=1489991
Summary: [meta] Add MOZ_LOG logging to ServiceWorker implementation and DOM Cache Storage API implementation → Add logging to ServiceWorker implementation exposed via about:serviceworkers
Summary: Add logging to ServiceWorker implementation exposed via about:serviceworkers → [meta] Add logging to ServiceWorker implementation exposed via about:serviceworkers
Keywords: meta
Summary: [meta] Add logging to ServiceWorker implementation exposed via about:serviceworkers → Add logging to ServiceWorker implementation exposed via about:serviceworkers
Blocks: 1669224
Blocks: 1666761
Attached patch p2: patch enhancements (obsolete) (deleted) — — Splinter Review
Attachment #9259820 - Attachment description: Initial about:serviceworkers patch that went up on moz-phab → p1: Initial about:serviceworkers patch that went up on moz-phab
Attached patch p3 patch enhancements (obsolete) (deleted) — — Splinter Review
Attached patch p4 patch enhancements (obsolete) (deleted) — — Splinter Review
Attachment #9259820 - Attachment description: p1: Initial about:serviceworkers patch that went up on moz-phab → p1: Actually a further revised version of what was in phabricator
Assignee: bugmail → nobody
Status: ASSIGNED → NEW
Attachment #9187978 - Attachment is obsolete: true

My empty try push also seemed to go through, so the revisions should be available in mercurial for a while: https://treeherder.mozilla.org/jobs?repo=try&revision=8539d60813f41b677efd1dc06e7dd3b6f30406a4

Attached patch swlog_p1.diff (obsolete) (deleted) — — Splinter Review
Attached patch swlog_p2.diff (obsolete) (deleted) — — Splinter Review
Attached patch swlog_p3.diff (obsolete) (deleted) — — Splinter Review
Attached file WIP: Bug 1506892 - sw_log_p2 (deleted) —

Depends on D136491

Attached file WIP: Bug 1506892 - sw_log_p3 (deleted) —

Depends on D136492

Attachment #9259870 - Attachment is obsolete: true
Attachment #9259871 - Attachment is obsolete: true
Attachment #9259872 - Attachment is obsolete: true

Comment on attachment 9259820 [details] [diff] [review]
p1: Actually a further revised version of what was in phabricator

(obsoleting these patches in favor of :jesup's de-bitrotted versions. The patch layering for these was not intentional, just an attempt to do append-only periodic commits that would later be cleaned up into a semantic stack.)

Attachment #9259820 - Attachment is obsolete: true
Attachment #9259821 - Attachment is obsolete: true
Attachment #9259822 - Attachment is obsolete: true
Attachment #9259823 - Attachment is obsolete: true
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: