Bug 182918 - Issue with Service Worker on trivago.com
Summary: Issue with Service Worker on trivago.com
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Service Workers (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-02-18 20:55 PST by Kenji Baheux
Modified: 2019-09-06 05:44 PDT (History)
4 users (show)

See Also:


Attachments
Screenshot showing the XHR failure (2.56 MB, image/png)
2018-02-18 20:55 PST, Kenji Baheux
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kenji Baheux 2018-02-18 20:55:01 PST
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&
Comment 1 Radar WebKit Bug Importer 2018-02-19 08:13:43 PST
<rdar://problem/37671402>
Comment 2 Chris Dumez 2018-02-19 08:30:49 PST
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).
Comment 3 Chris Dumez 2018-02-19 08:50:37 PST
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.
Comment 4 Chris Dumez 2018-02-19 09:30:26 PST
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.
Comment 5 Thomas Steiner 2018-02-21 14:29:17 PST
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
Comment 6 youenn fablet 2019-09-06 05:44:15 PDT
Marking bug as resolved. Please reopen if needed.