Issue metadata
Sign in to add a comment
|
Service Worker fetches randomly fail if dev tools is open
Reported by
a...@scirra.com,
Aug 28
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3535.0 Safari/537.36 Steps to reproduce the problem: 1. Visit https://editor.construct.net/r114/ 2. Open dev tools, and in the Application tab, go to 'Clear storage', tick everything, and click 'Clear site data' 3. Reload the main page 4. Check in the console and network tabs. A bunch of requests will have failed and reported console errors. Then repeat these steps, but close DevTools before step 3, and leave the main page showing for 10-20 seconds (so offline caching completes in the background) before opening DevTools. When you do that, the network panel shows all requests completed, and the console reports all resouces saved and offline support is ready. What is the expected behavior? Having DevTools open should not cause fetches to fail. What went wrong? Having DevTools open causes some Service Worker fetch requests to randomly fail. Did this work before? Yes Does this work in other browsers? Yes Chrome version: 70.0.3535.0 Channel: canary OS Version: 10.0 Flash Version: This is a regression since it definitely used to work in some prior Chrome version, but not sure which started failing. We started getting sporadic complaints about offline support no longer working in our PWA recently, so it may be that it broke in Chrome 68. The issue reproduces both in the current stable Chrome (68) and Canary (70).
,
Aug 29
Tried testing the issue reported chrome version #70.0.3535.0 using Windows 10 by following below steps. Steps: ===== 1.Launched chrome. 2.Navigated to 'https://editor.construct.net/r114/'. 3.Opened dev tools under the Application tab selected 'Clear storage'. 4.Selected everything and clicked 'Clear site data'. 5.Reloaded the main page. 6.Checked the console and network tabs but unable to see any errors. 7.Closed devtools and repeated step#2, Step#3, Step#4 and Step#5. 8.Waited for 10seconds and opened the console and network. 9.Observed that under console tab unable to see 'all resouces saved and offline support is ready' and under network tab could not see any request. Attached screencast for reference. @Reporter: Could you please review the attached screen-cast and confirm if anything being missed here. Thanks.!
,
Aug 29
,
Aug 29
You didn't follow the repro steps right: you're meant to leave devtools open to reproduce the issue, but you closed it.
,
Aug 29
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 30
Thanks for reporting this! I'm seeing a couple bugs around fetch event, and I'm suspecting this issue is related to issue 878667 or issue 879069 .
,
Aug 30
It is possible but the original report says it reproduces in stable 68 which shouldn't be affected by those issues unless ServiceWorkerServicification or NetworkService is enabled via chrome://flags. For what it's worth I couldn't reproduce on Mac 70 with ServiceWorkerServicification enabled.
,
Aug 30
I tried again in 70.0.3535.4 on Mac with ServiceWorkerServicification disabled this time and still can't repro this. ash@scirra, could you provide a NetLog? https://dev.chromium.org/for-testers/providing-network-details
,
Aug 30
Managed to reproduce and capture a NetLog in Canary 70.0.3537.0: https://www.dropbox.com/s/ferkrhv352vux7x/chrome-net-export-log.zip?dl=0 Also attached two screenshots showing lists of failed requests, and the headers for the first failed request. This is tough to reproduce because it seems the "Clear site data" button doesn't always work. Sometimes when I click that and reload the tab the SW then reports "Up to date", which is what would happen if all the data was left behind and the page reloaded. It seems you need to retry a couple of times before it happens.
,
Aug 30
Thanks. Unfortunately the netlog doesn't seem to capture the failed loads. I just see one event "HTTP_SERVER_PROPERTIES" when I open it in chrome://net-internals -> Import. I notice in the screenshot "Disable cache" is selected in DevTools. Is that needed to reproduce the issue for you?
,
Aug 30
also the netlog says it's from 68.0.3440.106 rather than 70.0.3537.0... is it the wrong netlog?
,
Aug 31
Tried testing the issue as per comment #4 on chrome version #70.0.3537.0. Observed no errors in console and no failed requests under network tab which was mentioned in comment#0-Step4. Attached screencast for reference. @reporter: Could you please review the screencas and let us know if anything is being missed here. If possible request you provide screencast of the issue, so that it would be really helpful for better triaging of the issue.As per comment#6, could you please confirm whether the issue is related to issue 878667 or issue 879069 . Thanks.!
,
Sep 4
I've also been seeing an issue like this (on Mac, 69.0.3497.72) - all requests will hang waiting for the service worker, they will all be in the pending state in devtools. This seems to happen not on the initial page load, but after a short period of time, and once this bug is triggered I can't load the site in new tabs either. I put a breakpoint on the event listener in the serviceworker for 'fetch' and when this issue is happening, the event listener is not called, as soon as the issue comes right then the breakpoint fires so I know the breakpoint is working. This seems to sometimes fix itself after a few minutes, and it seems that also pressing the test sync button in the Application -> Service worker tab in devtools would wake up the service worker and fix it. I'll record a screencast next time this happens for me.
,
Sep 4
Here's a screencast: https://www.youtube.com/watch?v=3VObX47W9Uc&feature=youtu.be It looks to me like this is related to 878667 , though I'm not sure if they realised the impact could be this large.
,
Sep 4
Yes c#13 sounds exactly like issue 878667 . I thought the original issue reported here is different because the report says it reproduces on stable Chrome 68 which shouldn't be affected by issue 878667 .
,
Sep 6
,
Sep 7
Chrome updated to 69.0.3497.81 so I tested again with that. I could definitely reproduce the issue once, but it seems random and trying a couple of dozen times after that I couldn't reproduce it again. So I've been unable to get a NetLog so far.
,
Sep 7
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 10
Thanks for the update. As per comment #15, this issue is similar to issue 878667 . Hence merging this to issue 878667 . Please feel free to undupe if it is not the case. Thanks.. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by viswa.karala@chromium.org
, Aug 28