Created attachment 334135 [details] Screenshot showing the XHR failure Filing on behalf of Jeffrey Posnick: Setup: Technology Preview 49 https://www.trivago.com Uses a custom bundle of Workbox [1] Issues observed: - At one point, I received a "This page was automatically reloaded due to an error" (or message along those lines). I couldn't capture any logs or screenshot. - When visiting a search page [2] and reloading a few times, I was able to get into a situation in which an XHR request failed due "access control checks". The strange thing is that a) I don't belive the SW intercepts that traffic and b) it's a same-origin request. [ATTACHMENT] - The offline-game functionality works as expected. The failed XHR is strange, though, and I was able to trigger a mysterious forced-reload. [1]: Original Workbox at https://developers.google.com/web/tools/workbox/ [2]: https://www.trivago.com/?aDateRange%5Barr%5D=2018-02-27&aDateRange%5Bdep%5D=2018-02-28&aPriceRange%5Bfrom%5D=0&aPriceRange%5Bto%5D=0&iPathId=35013&aGeoCode%5Blat%5D=32.776199&aGeoCode%5Blng%5D=-96.799103&iGeoDistanceItem=0&aCategoryRange=0%2C1%2C2%2C3%2C4%2C5&aOverallLiking=1%2C2%2C3%2C4%2C5&sOrderBy=relevance%20desc&bTopDealsOnly=false&iRoomType=7&cpt=3501303&iIncludeAll=0&iViewType=0&bIsSeoPage=false&bIsSitemap=false&
<rdar://problem/37671402>
For the "This page was automatically reloaded due to an error". This means that you experienced a WebContent process crash. It would be useful to provide the crash trace (see crash files for WebContent in the console app).
I have been browsing on trivago.com for a while now. For now, I haven't been able to reproduce the crash or the XHR error yet. I see that the region file is sometimes served by the service worker.
Still no luck reproducing the crash. However, I was able to reproduce the occasional XHR / Fetch load error with an AccessControl error message by reloading shortly after the page is loaded. The load error is actually a cancellation because we are reloading while initiating the XHR/Fetch load, and is merely misreported as an access control error. We hit this error in CachedResource::load(CachedResourceLoader&): if (m_options.securityCheck == DoSecurityCheck && (frameLoader.state() == FrameStateProvisional || !frameLoader.activeDocumentLoader() || frameLoader.activeDocumentLoader()->isStopping())) { if (frameLoader.state() == FrameStateProvisional) { RELEASE_LOG_IF_ALLOWED("load: Failed security check -- state is provisional (frame = %p)", &frame); And the call site (CachedResourceLoader::requestResource) ends up doing: resource->load(*this); // We don't support immediate loads, but we do support immediate failure. if (resource->errorOccurred()) { if (resource->allowsCaching() && resource->inCache()) memoryCache.remove(*resource); auto resourceError = resource->resourceError(); // Synchronous cancellations are likely due to access control. if (resourceError.isNull() || resourceError.isCancellation()) return makeUnexpected(ResourceError { String(), 0, url, String(), ResourceError::Type::AccessControl }); return makeUnexpected(resourceError); } Synchronous cancellation is usually due to AccessControl, however, it is not always. This is a bit unfortunate but not a big issue AFAICT. This is merely a cancellation due to a reload and nothing is broken. To make this bug actionable, please provide a crash trace when you experience the crash.
FWIW, trivago has worked flawlessly for me, apart from the issues tracked in https://bugs.webkit.org/show_bug.cgi?id=182874 and https://bugs.webkit.org/show_bug.cgi?id=182070. Not sure if this is helpful, but still maybe worth sharing. Cheers, Tom
Marking bug as resolved. Please reopen if needed.