Workbox: Samsung Internet browser throws an error when cached resources get requested

[Schepp]

Library Affected:
workbox-sw 3.0.0

Browser & Platform:
Samsung Internet 6.4.10.5

Issue or Feature Request Description:
I created a Service Worker with the help of Workbox. This is the SW's source code:

https://gist.github.com/Schepp/adbc1579e8d1a38087e087a40b205322

This is the page in which context it is running:
https://templates.park.works
User: templates
PW: gera16

Upon page load, I perform a SW precaching of HTML pages, by searching all <a> elements for URLs and by prefetching them via <link rel="prefetch"> element. When idle the browser fetches these URLs and the SW then caches them in the background (see source code above).

This works well on Chrome and Safari. On Samsung Internet though, the page only works upon the first visit. Once I reload the page, or navigate to a linked page, this is what I get:

When I look into Samsung Internet's internet://serviceworker-internals I spot these error messages:

Console: {"lineNumber":0,"message":"The FetchEvent for \"https://templates.park.works/\" resulted in a network error response: the promise was rejected.","message_level":2,"sourceIdentifier":1,"sourceURL":""}
Console: {"lineNumber":1,"message":"Uncaught (in promise) InvalidStateError: Failed to execute 'waitUntil' on 'ExtendableEvent': The event handler is already finished.","message_level":3,"sourceIdentifier":1,"sourceURL":"https://storage.googleapis.com/workbox-cdn/releases/3.0.0/workbox-strategies.prod.js"}
Console: {"lineNumber":0,"message":"The FetchEvent for \"https://templates.park.works/\" resulted in a network error response: the promise was rejected.","message_level":2,"sourceIdentifier":1,"sourceURL":""}
Console: {"lineNumber":1,"message":"Uncaught (in promise) InvalidStateError: Failed to execute 'waitUntil' on 'ExtendableEvent': The event handler is already finished.","message_level":3,"sourceIdentifier":1,"sourceURL":"https://storage.googleapis.com/workbox-cdn/releases/3.0.0/workbox-strategies.prod.js"}
Console: {"lineNumber":0,"message":"The FetchEvent for \"https://templates.park.works/\" resulted in a network error response: the promise was rejected.","message_level":2,"sourceIdentifier":1,"sourceURL":""}
Console: {"lineNumber":1,"message":"Uncaught (in promise) InvalidStateError: Failed to execute 'waitUntil' on 'ExtendableEvent': The event handler is already finished.","message_level":3,"sourceIdentifier":1,"sourceURL":"https://storage.googleapis.com/workbox-cdn/releases/3.0.0/workbox-strategies.prod.js"}
Console: {"lineNumber":0,"message":"The FetchEvent for \"https://templates.park.works/\" resulted in a network error response: the promise was rejected.","message_level":2,"sourceIdentifier":1,"sourceURL":""}
Console: {"lineNumber":1,"message":"Uncaught (in promise) InvalidStateError: Failed to execute 'waitUntil' on 'ExtendableEvent': The event handler is already finished.","message_level":3,"sourceIdentifier":1,"sourceURL":"https://storage.googleapis.com/workbox-cdn/releases/3.0.0/workbox-strategies.prod.js"}
Console: {"lineNumber":0,"message":"The FetchEvent for \"https://templates.park.works/\" resulted in a network error response: the promise was rejected.","message_level":2,"sourceIdentifier":1,"sourceURL":""}
Console: {"lineNumber":1,"message":"Uncaught (in promise) InvalidStateError: Failed to execute 'waitUntil' on 'ExtendableEvent': The event handler is already finished.","message_level":3,"sourceIdentifier":1,"sourceURL":"https://storage.googleapis.com/workbox-cdn/releases/3.0.0/workbox-strategies.prod.js"}
Console: {"lineNumber":0,"message":"The FetchEvent for \"https://templates.park.works/\" resulted in a network error response: the promise was rejected.","message_level":2,"sourceIdentifier":1,"sourceURL":""}
Console: {"lineNumber":1,"message":"Uncaught (in promise) InvalidStateError: Failed to execute 'waitUntil' on 'ExtendableEvent': The event handler is already finished.","message_level":3,"sourceIdentifier":1,"sourceURL":"https://storage.googleapis.com/workbox-cdn/releases/3.0.0/workbox-strategies.prod.js"}

Could it have to do with the basic auth?

[jeffposnick]

Can you try the same code with Workbox v3.1.0?

That release includes a fix for what sounds like the underlying issue: https://github.com/GoogleChrome/workbox/pull/1392

[Schepp]

I switched it out and it worked right away. Thank you @jeffposnick!!!

[dYb]

@jeffposnick
Sorry but still got this problem with version 3.1.0 on samsung mobile
Library Affected:
workbox-sw 3.1.0

Browser & Platform:
Mozilla/5.0 (Linux; Android 7.0; SAMSUNG SM-G9550 Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/6.4 Chrome/56.0.2924.87 Mobile Safari/537.36

Issue or Feature Request Description:
page url: https://c.m.163.com/news/b/bd_a884938fd9af4ef79267f6a8688769de_4.html
workbox config: https://gist.github.com/dYb/eb5a2b6145dd0a9be6ddfe862fcd8539

when I changed handler from staleWhileRevalidate to networkFirst, it worked right.
there is a screenshot of the error.

[Alivejke]

Same here, problem is not solved. @jeffposnick can you please reopen the issue?

[jeffposnick]

I managed to get chrome://inspect/ to show some underlying errors when using staleWhileRevalidate from within Samsung Internet 6.4:

That's a good lead and I'll investigate further.

[jeffposnick]

Based on that, I believe that we need to update the StaleWhileRevalidate strategy in the same manner as NetworkFirst was updated in https://github.com/GoogleChrome/workbox/pull/1392

(I'll also use this as an opportunity to audit the other strategies to see if there's any other instances where event.waitUntil() might be called asynchronously.)

[romandev]

@jeffposnick

Hi, I'm Jinho Bang and a Samsung Internet browser developer.

I'm here because we got reported this issue from some users. Sadly, the asynchronos waitUntil() is not implemented yet in our browser. Yes, we will implement it but our release cycle is so far. So, for a long time, we might not resolve the issue.

So, my question is whether it is possible to backport your fix to 3.1 v as well.
I'm not sure but many sites seems still using 3.1v. (e.g. globo.com)
If you could update 3.1v in CDN side, we might resolve this issue easily.

WDYT?

[romandev]

@jeffposnick Gentle ping :)

[jeffposnick]

Hello @romandev—Our policy is not to do post-release changes without bumping a version number, following general semantic versioning principles.

And in any case, due to the way that importScripts() is aggressively cached, it's not likely that any changes would actually get propagated out to existing users—you really need to update the URL to ensure that imported scripts are retrieved again.

It's up to developers to manage their dependencies on Workbox and update as they see fit. I know that's frustrating when there's a bug fix that a developer is missing out on, but encouraging that developer to upgrade is the only course of action.

[romandev]

@jeffposnick,

Looks reasonable to me. Thank you for detailed explanation. :)