Issue metadata
Sign in to add a comment
|
Initiator in Service Worker causing fetch to fail
Reported by
chr...@pinckneyhugo.com,
Nov 16
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Steps to reproduce the problem: Steps to reproduce the problem: 1. Load a page that installs a service worker (maybe only specific sites?) 2. Simple reload will trigger the offline page from cache (or a connection error page) What is the expected behavior? What is the expected behavior? 1. Load a page that installs a service worker 2. Simple reload will load the same page from cache What went wrong? The Fetch API is successfully loading other resources, but fails (without additional context to the error message- only "Failed to fetch") when attempting to load the home page. When reloading, it attempts to load the home page via Fetch API and when it fails, it delivers the cached offline page (if available) or the browser's network connection error page. Did this work before? Yes Chromium 66 Does this work in other browsers? Yes Chrome version: 70.0.3538.102 Channel: stable OS Version: OS X 10.14.1 Flash Version: After discussing this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=874173 with the extension developer he mentioned that it may not actually be caused by the extension. I wanted to check a few more production releases of Chrome and the problem I'm running into is still happening regardless of version (currently 70). https://github.com/uBlockOrigin/uBlock-issues/issues/173 It only happens when that extension is installed/active, but the developer mentioned that it is related to *this* Chromium issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=834734 I'll admit that I'm a little beyond my knowledge of the inner workings of Chrome, so I'm afraid I can't add much more detail than the Github Issue transcript I provided, but I'm happy to provide any additional information needed to help troubleshoot this. The screenshots from the initial report here are still occurring for me (I've kept my notes in my own Github repo here: https://github.com/chrisblakley/Nebula/issues/1709). To reiterate from the first issue, the test case I attached is just two basic Fetch API calls with 2 different pages. This is happening on my website: https://gearside.com/nebula/ and the test case I attached is a snippet I have inside of my service worker file. The console and Network tab in DevTools will show the "A" group as successful, but the B group will fail. I'm sorry this is so confusing, but I've reached the limit of my abilities to troubleshoot this so I'm not entirely sure where the actual problem is, but it seems to have something to do with the initiator in Chrome and how it works with Service Workers (which is causing conflicts with extensions)...
,
Nov 19
I'm suspecting that issue 884007 (loading at launching the browser fails when an extension using webRequest API is installed) would be related to this. Could you try a few configurations as follows? Step 1: Open chrome://flags Step 2: Set #enable-service-worker-servicification and #network-service as follows Case 1) #enable-service-worker-servicification to off, #network-service to off Case 2) #enable-service-worker-servicification to on, #network-service to off Case 3) #enable-service-worker-servicification to on, #network-service to on Step 3: Restart the browser and try the site. Also, could you try Chrome Canary too? It's the latest version of Chrome, so it should have a fix of issue 884007 . If you can reproduce the issue in any of cases on Chrome Canary, there might be another issue. I'd be happy to help.
,
Nov 19
,
Nov 19
Ok, I've run each of those cases as well as in Chrome Canary. Here are my results: Chrome 70 - Case 1: Same issue as described (no change) - Case 2: Same issue as described (no change) - Case 3: No error (issue fixed in this case) Chrome Canary (71) - Case 1: No error (issue fixed in this case) - Case 2: No error (issue fixed in this case) - Case 3: No error (issue fixed in this case) This seems promising. In my previous attempt last summer I was not able to recreate the problem in Chrome Canary, but it also did not have the same extension installed. This time I ran Canary with that extension and it seems to be ok. I'll be looking forward to Dec 4th to check this again in the stable release of Chrome 71. I'll update this issue if I have any problems, and in the meantime if you'd like me to run any additional tests I'd be more than happy, thanks.
,
Nov 19
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
,
Nov 20
Thanks for your feedback. I'm wondering if Chrome Canary would be M72 (stable version + 2), but the fix was actually in M71 so that should be okay too. So far let me mark this issue as WONTFIX, but feel free to add your comments if you see something wrong after the next Chrome update. Thanks!
,
Dec 4
Hey just confirming that this is resolved in the stable release of Chrome 71. Thanks!
,
Dec 5
Great to hear, thanks! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Nov 18