New issue
Advanced search Search tips

Issue 753646 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Aug 2017
Cc:
yhirano@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

service worker streamed navigation stops after long period, but devtools claims the SW is still alive

Reported by bke...@mozilla.com, Aug 9 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0

Steps to reproduce the problem:
1. Visit this page: https://html-sw-stream.glitch.me/
2. Possibly reload to get the service worker controlling the page.
3. Observe both iframes updating once per second.
4. Wait for 5.5 minutes.
5. Observe the server streamed iframe continues to update, but the service worker streamed iframe has stopped.
6. Open devtools application panel
7. Observe that devtools says the service worker is "activated and is running".

What is the expected behavior?

What went wrong?
It seems like one of the the following should have happened:

1. The response body should continue streaming indefinitely.
2. The lifetime of the service worker is timed out and the service worker is killed.

It seems unusual that the service worker is alive, but no longer streaming.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: <Copy from: 'about:version'>  Channel: n/a
OS Version: 10.0
Flash Version:

Comment 1 by bke...@mozilla.com, Aug 9 2017 

I seem to get this in the console:

GET https://html-sw-stream.glitch.me/sw-stream-frame.html net::ERR_CONNECTION_RESET

I still don't understand why the SW would stay alive.  My js stream tries to drop its waitUntil() promise if controller.enqueue() throws:

  evt.waitUntil(new Promise(resolve => {
    let body = new ReadableStream({
      start: controller => {
        let encoder = new TextEncoder();
        controller.enqueue(encoder.encode('<!doctype html><html><head><meta charset="utf-8"/></head><body>\n'));
        let count = 0;
        function tick() {
          try {
            count += 1;
            controller.enqueue(encoder.encode('<p>' + count + ' seconds since response start.</p>\n')); 
          } catch(e) {
            resolve();
          }
        }
        setInterval(tick, 1000);
      },
    });
    evt.respondWith(new Response(body));

And I would imagine the respondWith() should not keep it alive given the "reset" either.

Comment 2 by bke...@mozilla.com, Aug 9 2017 

Source code for the demo is here:

https://glitch.com/edit/#!/html-sw-stream

Comment 3 by yhirano@chromium.org, Aug 9 2017

Cc: yhirano@chromium.org
Components: Blink>ServiceWorker Blink>Network>FetchAPI

Comment 4 by yhirano@chromium.org, Aug 9 2017 

Not reproducible on Version 60.0.3112.90 (Official Build) (64-bit) on Linux.

Which chrome version are you using?

Comment 5 by bke...@mozilla.com, Aug 9 2017 

Version 60.0.3112.90 (Official Build) (64-bit)

On windows.

I can try to get a screenshot...

Comment 6 by bke...@mozilla.com, Aug 9 2017 

Hmm.  Now I can't reproduce either.  Maybe I got an update?  Or maybe its intermittent?

I'll try to reproduce again tomorrow.  Sorry for the noise if its already fixed.

Comment 7 by horo@chromium.org, Aug 9 2017

Status: WontFix (was: Unconfirmed)
It is working as intended.

Chrome stops the service worker after 5+ minutes timeout even if it is streaming.

https://chromium.googlesource.com/chromium/src/+/edcdf0a5b0f36f08372133f1712444ae61f88ba4/content/browser/service_worker/service_worker_version.cc#60

When you open the DevTools, Chrome restarts the service worker.
So you see the running service worker in the DevTools.

You can check the stopped service worker in chrome://serviceworker-internals/.

Comment 8 by bke...@mozilla.com, Aug 9 2017 

Ah, thanks.  I didn't realize devtools restarted it.
►

Sign in to add a comment