Bug 257252 – HTTP multi-part responses cannot be intercepted by service workers

• Status: NEW
• Component: Page Loading

[fasc]

I Use a mjpeg stream for a intercom appilaction.

The stream/visualisation works finde within the Browser (Safari/Chrome).
But if the app is installed as pwa it doesn't work any longer, the screen stays black.

Bug is present since iOS 16.4 and upwards.

[Alexey Proskuryakov]

Thank you for the report! Do you happen to have a publicly accessible example where this reproduces?

[Radar WebKit Bug Importer]

<rdar://problem/109797360>

[fasc]

(In reply to Alexey Proskuryakov from comment #1)
> Thank you for the report! Do you happen to have a publicly accessible
> example where this reproduces?

Hi Alexey 
Yes, but I don't want to post the link here.
I will send you an Email with the credentials.

[fasc]

Dear all

Did someone reproduce the bug with the shared application?

[fasc]

Dear all

I have some news regarding the problem:

- Bug is still present in iOS 17.

- The mjpeg stream is displayed correctly withhin the PWA, if the follwing flag on iOS is deactivated : Safari -> Experimental Features -> Service Worker.

- Deactivating the Service Worker gives other problems with the pwa, so this is no solution. But this information could for debugging purposes be helpful.

[Chris Dumez]

(In reply to fasc from comment #5)
> Dear all
> 
> I have some news regarding the problem:
> 
> - Bug is still present in iOS 17.
> 
> - The mjpeg stream is displayed correctly withhin the PWA, if the follwing
> flag on iOS is deactivated : Safari -> Experimental Features -> Service
> Worker.
> 
> - Deactivating the Service Worker gives other problems with the pwa, so this
> is no solution. But this information could for debugging purposes be helpful.

You said this is a regression in iOS 16.4. However, I tried older builds of WebKit and could still reproduce. I was unable to find a regression point on WebKit side.

Since the issue is related to service workers, did you start adopting service workers when it regressed maybe?

I'm looking at our code and it appears our service workers don't work well with multi-part responses. However, I don't see evidence yet that this ever worked.

[Chris Dumez]

Also note that I can reproduce in Safari on macOS as well.
It is also broken in Firefox on macOS (though Firefox is able to display the first frame at least).

[Chris Dumez]

I just tried on iOS 16.0 and the page indeed works. However, it also doesn't use a service worker at all.

So I looked at your code and found:
```
if('serviceWorker' in navigator && 'PushManager' in window && !top.isPanel && !isRemote && sessionid)
	{
		navigator.serviceWorker.register(defpath+'library/'+sitelg+'/worker.js',{scope:location.origin+defpath}).then(function(reg) {
```

While iOS 16.0 already supported service workers (and thus `navigator.serviceWorker` existed), we likely didn't support the PushManager then. As a result, no service worker was register.

We likely added support or the Push API (exposing `window.PushManager` in iOS 16.4), causing your app to take a different code path and register a service worker. The service worker intercepts loads, including the one for the mjpeg "stream" (which relies on multi-part HTTP responses).

However, our service workers have never supported intercepting multi-part HTTP responses as far as I can tell. As a matter of fact, we have a piece of code that cancels the load as soon as we realize it is multi-part and this piece of code has been there for a long time.

So to summarize, there was no "real" regression in iOS 16.4. We shipped a new feature which caused a new code path to get exercised in your app and this code path is not compatible with WebKit's implementation of service workers (and maybe not Firefox's either based on my testing?).

Implementing support for service worker interception of multi-part responses is likely not trivial (Though Youenn is more familiar with this part of the code).

I don't have a good workaround on WebKit side either. We don't know the load is going to get a multi-part response at the point where we decide to use the service worker and the service worker choses to intercept it. So we can't really bypass the service worker and go straight to the network for this load.

[fasc]

Thanks for your feedback.

We switched from the mjpeg stream to single images.
Therefore multi-part messages aren't used any more, and the issue is temporarily solved.

Regarding the performance, I would encourage you to support multi-part messages with the service worker.