New issue
Advanced search Search tips

Issue 878409 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Aug 30
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

ServiceWorker.StartWorker.Time is not always recorded

Project Member Reported by wanderview@chromium.org, Aug 28

Issue description

What steps will reproduce the problem?
1. Launch new browser instance
2. In one tab open chrome://histograms/ServiceWorker.StartWorker.Time
3. In second tab open chrome://histograms/ServiceWorker.StopWorker.Time
4. In third tab open https://fetch-event-echo.glitch.me
5. Refresh histogram tabs and observe there is a sample for StartWorker.Time.
6. Open devtools for fetch-event-echo tab and stop the service worker from the application tab.
7. Refresh histograms and observe there is a sample for StopWorker.Time
8. From devtools on fetch-event-echo tab, execute `fetch("/")` to trigger another FetchEvent
9. Observe in devtools that the service worker is running
10. Refresh histograms

What is the expected result?

The StartWorker.Time histogram should have a new sample from the worker starting in step (8).

What happens instead?

There is no new StartWorker.Time sample recorded.

This is probably a minor issue since worker start time is most critical on navigations.  I'm filing the bug, though, since it seems unintentional and might skew analysis of the data.
 
Cc: falken@chromium.org
Maybe we intentionally don't record StartWorker.Time when DevTools is attached.

https://cs.chromium.org/chromium/src/content/browser/service_worker/service_worker_version.cc?l=820&rcl=c08ef6f7e72cf72e378ca36c22d328c3795ba2f1

When we use content_shell with --expose-internals-for-testing flag, we can call internals.terminateServiceWorker(navigator.serviceWorker.controller) to terminate the service worker. I did followings:

1. Add a debug print line in ServiceWorkerMetrics::RecordStartWorkerTime()
2. Prepare a page that registers a sw. The page has two buttons that trigger fetch() and terminateServiceWorker(), respectively.
3. Open the page and make sure the sw is controlling the page.
4. Press a button to terminate the sw. After that press the other button to trigger fetch().

I confirmed that RecordStartWorkerTime() is called at step 4. I think this is WAI. WDYT falken@?
Status: WontFix (was: Untriaged)
Yes I think you're right. We skip UMA when DevTools is "attached" to the service worker, but I'm not sure what attached means. It looks like once DevTools is open the tab gets poisoned and even if we close DevTools there's no more start timing recorded from that tab.

I could see the start worker get recorded with the following:
1. In a new tab, open https://console-print-headers.glitch.me/
2. In another tab, open chrome://serviceworker-internals/ and stop the worker.
3. In another tab, open chrome://histograms/ServiceWorker.StartWorker.Time
4. Go back to the first tab and click 'fetch from page'.
5. In the histograms tab, refresh, and see a new sample.

However once I opened DevTools everything got a bit unpredictable and I had trouble seeing new samples, even after DevTools was closed. That seems a bit unfortunate but probably won't skew data too much. So I think we can call this WAI. Thanks for the detailed report.

Sign in to add a comment