Bug 245249

Summary:	REGRESSION (iOS 16): Worker content security policy limits outer page
Product:	WebKit	Reporter:	Nicholas Butko <nb>
Component:	Service Workers	Assignee:	Nobody <webkit-unassigned>
Status:	RESOLVED WONTFIX
Severity:	Normal	CC:	bfulgham, cdumez, christoph, rigel, tony, webkit-bug-importer, wilander, youennf
Priority:	P2	Keywords:	InRadar
Version:	WebKit Nightly Build
Hardware:	iPhone / iPad
OS:	Other
See Also:	https://bugs.webkit.org/show_bug.cgi?id=245530

Description Nicholas Butko 2022-09-15 15:33:26 PDT

* This is a Worker() issue, not a Service Worker issue, but there is no Worker component *

* This is an iOS 16 issue but there is no iOS 16 dropdown for OS */

On iOS 16 we are seeing web workers fail to load. The workers are loaded from a page without a content security policy header. The workers themselves are served with https header `content-security-policy: sandbox; default-src none`. The intent is for the outer page to load and run the worker, but to sandbox the worker itself.

This works well on chrome and all recent versions of iOS prior to 16.

On iOS 16, the worker:
- Fails to load the URL (it doesn't show up in the network inspector tag).
- Does not report a security error.
- Calls onerror event with no message or details about the nature of the error. This is of type Event, not ErrorEvent.

It would be great to fix this so that the site can still load the worker.

If the error is intended, the onerror event should be an ErrorEvent with a message.

Comment 1 Radar WebKit Bug Importer 2022-09-15 18:24:12 PDT

<rdar://problem/100004674>

Comment 2 Christoph Bartschat 2022-09-19 15:25:40 PDT

To provide some additional background, we found that the discrepancy was not related to CSP, but instead the Content-Type header.

It seems like the Content-Type did not affect this before, so there would have been a breaking change since iOS 15.7.


We can see the behavior in the following demo.

For the correct behavior, we should load and see messages from all 3 workers, but on iOS 16.0, we only see one.

We also don't get any indication on why it failed.


Example:
https://nova-acoustic-lightyear.glitch.me/

Source:
https://glitch.com/edit/#!/nova-acoustic-lightyear

Comment 3 youenn fablet 2022-09-20 14:14:58 PDT

ResourceResponseBase mimeType is either empty or application/octet-stream in the last two cases.
The mime type check then fails.
It might be a regression from hardening done in https://bugs.webkit.org/show_bug.cgi?id=236411

Comment 4 youenn fablet 2022-09-21 09:26:36 PDT

Safari latest implementation is aligned with the spec and Firefox.
Chrome is doing some work to align with the spec as well though this has not shipped yet.

@Nicholas, @Christoph, were you able to fix this on server side?
If so, I would be tempted to mark this as 'Behave as expected'.

Comment 5 Nicholas Butko 2022-09-21 16:25:21 PDT

In that case, the unexpected thing is that onerror handler returns an Event that is not an ErrorEvent, and that it has no message about the nature of the error. We could have diagnosed and fixed the issue a lot faster if there was a message like "Invalid mime type for worker: application/octet-stream"

Comment 6 youenn fablet 2022-09-21 16:47:56 PDT

(In reply to Nicholas Butko from comment #5)
> In that case, the unexpected thing is that onerror handler returns an Event
> that is not an ErrorEvent, and that it has no message about the nature of
> the error. We could have diagnosed and fixed the issue a lot faster if there
> was a message like "Invalid mime type for worker: application/octet-stream"

Right, would logging an error in the JS console with such message be good enough?

Comment 7 youenn fablet 2022-09-22 11:30:32 PDT

I filed https://bugs.webkit.org/show_bug.cgi?id=245530 to follow-up on adding console logging to help web developer investigations.

Comment 8 youenn fablet 2022-09-22 11:31:44 PDT

Tentatively marking as WontFix given the potential server-side fix and the fact we are aligned to the spec and Firefox, and the desire to Chrome to align in the short future.