Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Intent to Ship: Fire error event instead of throwing for CSP blocked worker

289 views
Skip to first unread message

Liang Zhao (REDMOND)

unread,
Jan 13, 2025, 5:31:23 PMJan 13
to blin...@chromium.org, hiro...@chromium.org, mk...@chromium.org

Contact emails

lz...@microsoft.com


Explainer

None


Specification

https://fetch.spec.whatwg.org/#concept-main-fetch


Summary

When blocked by CSP, Chromium currently throws SecurityError from constructor. Spec requires CSP to be checked as part of fetch and fires error event asynchronously. This aims to make Chromium spec conformant, which is not throwing during constructor and fires error event asynchronously.




Blink component

Blink>SecurityFeature>ContentSecurityPolicy


TAG review

None


TAG review status

Not applicable


Risks




Interoperability and Compatibility

Currently Firefox works as spec-ed while Safari works the same as Chrome. With the wrong test code in WPT tests, Firefox is failing the tests: https://wpt.fyi/results/content-security-policy/worker-src/dedicated-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned https://wpt.fyi/results/content-security-policy/worker-src/shared-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned After updating Chrome code and WPT tests, Firefox passes the tests while Safari fails the tests.



Gecko: Shipped/Shipping

WebKit: No signal

Web developers: No signals

Other signals: This changes the behavior the same as Firefox.


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?




Debuggability

When worker is blocked by CSP, there is DevTools message logged about the blocking by CSP. This behavior is not changed.




Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/content-security-policy/worker-src/dedicated-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned https://wpt.fyi/results/content-security-policy/worker-src/shared-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned Note that the test code currently has the wrong expectation and will be updated as part of this feature work.




Flag name on about://flags

None


Finch feature name

None


Non-finch justification

This is a simple change of behavior for uncommon scenario where worker is blocked by CSP, and the changed behavior is the same as Firefox and spec aligned. It is unlikely that a site depends on the current behavior of throwing exception for blocked worker.




Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/41285169


Estimated milestones

Shipping on desktop

134

DevTrial on desktop

134

Shipping on Android

134

DevTrial on Android

134

Shipping on WebView

134




Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5177205656911872?gate=5108732671033344

Stephen Chenney

unread,
Jan 14, 2025, 8:39:28 AMJan 14
to Liang Zhao (REDMOND), blin...@chromium.org, hiro...@chromium.org, mk...@chromium.org
On Mon, Jan 13, 2025 at 5:31 PM 'Liang Zhao (REDMOND)' via blink-dev <blin...@chromium.org> wrote:

Contact emails

lz...@microsoft.com


Explainer

None


Specification

https://fetch.spec.whatwg.org/#concept-main-fetch


Summary

When blocked by CSP, Chromium currently throws SecurityError from constructor. Spec requires CSP to be checked as part of fetch and fires error event asynchronously. This aims to make Chromium spec conformant, which is not throwing during constructor and fires error event asynchronously.


Does Chromium throw the exception _and_ send the event?
I believe this needs a flag. While unlikely that anyone is depending on this it is not possible to be sure.

In addition, I strongly advise a use counter, if possible, to see how often this code path gets hit, to verify "unlikely". That does not remove the need for a flag because not all installs report UMA data.
 




Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/41285169


Estimated milestones

Shipping on desktop

134

DevTrial on desktop

134

Shipping on Android

134

DevTrial on Android

134

Shipping on WebView

134




Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5177205656911872?gate=5108732671033344

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CO1PR00MB2285E0FC0FEC6768415E9F979E1F2%40CO1PR00MB2285.namprd00.prod.outlook.com.

Mike Taylor

unread,
Jan 14, 2025, 10:10:01 AMJan 14
to Liang Zhao (REDMOND), blin...@chromium.org, hiro...@chromium.org, mk...@chromium.org

On 1/13/25 5:19 PM, 'Liang Zhao (REDMOND)' via blink-dev wrote:

Contact emails

lz...@microsoft.com


Explainer

None


Specification

https://fetch.spec.whatwg.org/#concept-main-fetch


Summary

When blocked by CSP, Chromium currently throws SecurityError from constructor. Spec requires CSP to be checked as part of fetch and fires error event asynchronously. This aims to make Chromium spec conformant, which is not throwing during constructor and fires error event asynchronously.

Which constructor?




Blink component

Blink>SecurityFeature>ContentSecurityPolicy


TAG review

None


TAG review status

Not applicable


Risks




Interoperability and Compatibility

Are you able to expand on the compatibility implications for this change, i.e., do we know if Firefox has any site breakage as a result of their behavior? What scenarios might surprise developers who are relying on Chrome's current behavior, etc?

Currently Firefox works as spec-ed while Safari works the same as Chrome. With the wrong test code in WPT tests, Firefox is failing the tests: https://wpt.fyi/results/content-security-policy/worker-src/dedicated-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned https://wpt.fyi/results/content-security-policy/worker-src/shared-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned After updating Chrome code and WPT tests, Firefox passes the tests while Safari fails the tests.

Can you explain what you mean by wrong test code?



Gecko: Shipped/Shipping

WebKit: No signal

Web developers: No signals

Other signals: This changes the behavior the same as Firefox.


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?




Debuggability

When worker is blocked by CSP, there is DevTools message logged about the blocking by CSP. This behavior is not changed.




Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/content-security-policy/worker-src/dedicated-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned https://wpt.fyi/results/content-security-policy/worker-src/shared-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned Note that the test code currently has the wrong expectation and will be updated as part of this feature work.




Flag name on about://flags

None


Finch feature name

None


Non-finch justification

This is a simple change of behavior for uncommon scenario where worker is blocked by CSP, and the changed behavior is the same as Firefox and spec aligned. It is unlikely that a site depends on the current behavior of throwing exception for blocked worker.

Can we back up "it is unlikely" with some data? Absent that, I would strongly suggest we put this behind a flag.




Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/41285169


Estimated milestones

Shipping on desktop

134

DevTrial on desktop

134

Shipping on Android

134

DevTrial on Android

134

Shipping on WebView

134




Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5177205656911872?gate=5108732671033344

--

Liang Zhao

unread,
Jan 14, 2025, 5:34:11 PMJan 14
to blink-dev, Stephen Chenney, blin...@chromium.org, hiro...@chromium.org, mk...@chromium.org, Liang Zhao (REDMOND)
Updated the plan to have a new feature NoThrowForCSPBlockedWorker to control the new behavior. 

On Tuesday, January 14, 2025 at 5:39:28 AM UTC-8 Stephen Chenney wrote:
On Mon, Jan 13, 2025 at 5:31 PM 'Liang Zhao (REDMOND)' via blink-dev <blin...@chromium.org> wrote:

Contact emails

lz...@microsoft.com


Explainer

None


Specification

https://fetch.spec.whatwg.org/#concept-main-fetch


Summary

When blocked by CSP, Chromium currently throws SecurityError from constructor. Spec requires CSP to be checked as part of fetch and fires error event asynchronously. This aims to make Chromium spec conformant, which is not throwing during constructor and fires error event asynchronously.


Does Chromium throw the exception _and_ send the event?

The current Chromium behavior is throw exception only. As no worker object is returned, could not fire event on a worker object. 
Updated to use feature name NoThrowForCSPBlockedWorker now. FWIW, this is a scenario where the site tries to create a new Worker or SharedWorker object, but the url of the worker is blocked by its CSP, so the worker object is not created and related worker script would not run.

Liang Zhao (REDMOND)

unread,
Jan 14, 2025, 5:43:25 PMJan 14
to Mike Taylor, blin...@chromium.org, hiro...@chromium.org, mk...@chromium.org

 

 

From: Mike Taylor <mike...@chromium.org>
Sent: Tuesday, January 14, 2025 7:10 AM
To: Liang Zhao (REDMOND) <Liang...@microsoft.com>; blin...@chromium.org
Cc: hiro...@chromium.org; mk...@chromium.org
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: Fire error event instead of throwing for CSP blocked worker

 

You don't often get email from mike...@chromium.org. Learn why this is important

On 1/13/25 5:19 PM, 'Liang Zhao (REDMOND)' via blink-dev wrote:

Contact emails

lz...@microsoft.com



Explainer

None



Specification

https://fetch.spec.whatwg.org/#concept-main-fetch



Summary

When blocked by CSP, Chromium currently throws SecurityError from constructor. Spec requires CSP to be checked as part of fetch and fires error event asynchronously. This aims to make Chromium spec conformant, which is not throwing during constructor and fires error event asynchronously.

Which constructor?

The constructor of Worker and SharedWorker objects. Also updated the chromestatus so that it is clear.





Blink component

Blink>SecurityFeature>ContentSecurityPolicy



TAG review

None



TAG review status

Not applicable



Risks





Interoperability and Compatibility

Are you able to expand on the compatibility implications for this change, i.e., do we know if Firefox has any site breakage as a result of their behavior? What scenarios might surprise developers who are relying on Chrome's current behavior, etc?

 

We are not aware of any site breakage for Firefox due to its behavior. If a site has a worker that is blocked by CSP and has code after "new Worker()", those code currently does not run in Chrome or Safari, but runs in Firefox. After the change, those code would run in Chrome.



Currently Firefox works as spec-ed while Safari works the same as Chrome. With the wrong test code in WPT tests, Firefox is failing the tests: https://wpt.fyi/results/content-security-policy/worker-src/dedicated-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned https://wpt.fyi/results/content-security-policy/worker-src/shared-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned After updating Chrome code and WPT tests, Firefox passes the tests while Safari fails the tests.

Can you explain what you mean by wrong test code?

The current WPT test code expects exception to throw, which is not what’s required by the spec. The test code has a TODO comment states that the test code is wrong with a link to https://crbug.com/663298,



Gecko: Shipped/Shipping

WebKit: No signal

Web developers: No signals

Other signals: This changes the behavior the same as Firefox.



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?





Debuggability

When worker is blocked by CSP, there is DevTools message logged about the blocking by CSP. This behavior is not changed.





Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes



Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/content-security-policy/worker-src/dedicated-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned https://wpt.fyi/results/content-security-policy/worker-src/shared-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned Note that the test code currently has the wrong expectation and will be updated as part of this feature work.





Flag name on about://flags

None



Finch feature name

None



Non-finch justification

This is a simple change of behavior for uncommon scenario where worker is blocked by CSP, and the changed behavior is the same as Firefox and spec aligned. It is unlikely that a site depends on the current behavior of throwing exception for blocked worker.

Can we back up "it is unlikely" with some data? Absent that, I would strongly suggest we put this behind a flag.

Changed the plan to put this new behavior behind NoThrowForCSPBlockedWorker feature flag. Also updated the chromestatus.

Chris Harrelson

unread,
Jan 15, 2025, 11:25:48 AMJan 15
to Liang Zhao (REDMOND), Mike Taylor, blin...@chromium.org, hiro...@chromium.org, mk...@chromium.org
Please also fill out the various reviews in your chromestatus entry (privacy, security, enterprise, debuggability, testing).



Yoav Weiss (@Shopify)

unread,
Jan 16, 2025, 1:47:15 AMJan 16
to blink-dev, Chris Harrelson, Mike Taylor, blin...@chromium.org, Hiroshige Hayashizaki, Mike West, Liang Zhao (REDMOND)
On Wednesday, January 15, 2025 at 5:25:48 PM UTC+1 Chris Harrelson wrote:
Please also fill out the various reviews in your chromestatus entry (privacy, security, enterprise, debuggability, testing).



On Tue, Jan 14, 2025 at 2:43 PM 'Liang Zhao (REDMOND)' via blink-dev <blin...@chromium.org> wrote:

 

 

From: Mike Taylor <mike...@chromium.org>
Sent: Tuesday, January 14, 2025 7:10 AM
To: Liang Zhao (REDMOND) <Liang...@microsoft.com>; blin...@chromium.org
Cc: hiro...@chromium.org; mk...@chromium.org
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: Fire error event instead of throwing for CSP blocked worker

 

You don't often get email from mike...@chromium.org. Learn why this is important

On 1/13/25 5:19 PM, 'Liang Zhao (REDMOND)' via blink-dev wrote:

Contact emails

lz...@microsoft.com



Explainer

None


I think an explainer (or even an inline text explaining the change, providing an example, etc) would have significantly helped folks understand what it is that you're trying to ship.
Could you write something to that effect? 
This points at a relatively long algorithm. Can you point out the specific steps that are relevant here? 





Summary

When blocked by CSP, Chromium currently throws SecurityError from constructor. Spec requires CSP to be checked as part of fetch and fires error event asynchronously. This aims to make Chromium spec conformant, which is not throwing during constructor and fires error event asynchronously.

Which constructor?

The constructor of Worker and SharedWorker objects. Also updated the chromestatus so that it is clear.

An example demonstrating where developers need to catch those exceptions now would be helpful IMO. 





Blink component

Blink>SecurityFeature>ContentSecurityPolicy



TAG review

None



TAG review status

Not applicable



Risks





Interoperability and Compatibility

Are you able to expand on the compatibility implications for this change, i.e., do we know if Firefox has any site breakage as a result of their behavior? What scenarios might surprise developers who are relying on Chrome's current behavior, etc?

 

We are not aware of any site breakage for Firefox due to its behavior. If a site has a worker that is blocked by CSP and has code after "new Worker()", those code currently does not run in Chrome or Safari, but runs in Firefox. After the change, those code would run in Chrome.

Also, if sites are doing something as a result of catching a CSP failure exception, that would stop working (unless they shift to start listening to the relevant event), right? 



Currently Firefox works as spec-ed while Safari works the same as Chrome. With the wrong test code in WPT tests, Firefox is failing the tests: https://wpt.fyi/results/content-security-policy/worker-src/dedicated-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned https://wpt.fyi/results/content-security-policy/worker-src/shared-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned After updating Chrome code and WPT tests, Firefox passes the tests while Safari fails the tests.

Can you explain what you mean by wrong test code?

The current WPT test code expects exception to throw, which is not what’s required by the spec. The test code has a TODO comment states that the test code is wrong with a link to https://crbug.com/663298,



Gecko: Shipped/Shipping

WebKit: No signal

Have we asked for a signal from WebKit folks? 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Liang Zhao (REDMOND)

unread,
Jan 16, 2025, 8:25:50 PMJan 16
to Yoav Weiss (@Shopify), blink-dev, Chris Harrelson, Mike Taylor, blin...@chromium.org, Hiroshige Hayashizaki, Mike West

On Wednesday, January 15, 2025 at 5:25:48PM UTC+1 Chris Harrelson wrote:

Please also fill out the various reviews in your chromestatus entry (privacy, security, enterprise, debuggability, testing).

 

 

 

On Tue, Jan 14, 2025 at 2:43PM 'Liang Zhao (REDMOND)' via blink-dev <blin...@chromium.org> wrote:

 

 

From: Mike Taylor <mike...@chromium.org>
Sent: Tuesday, January 14, 2025 7:10 AM
To: Liang Zhao (REDMOND) <Liang...@microsoft.com>; blin...@chromium.org
Cc: hiro...@chromium.org; mk...@chromium.org
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: Fire error event instead of throwing for CSP blocked worker

 

You don't often get email from mike...@chromium.org. Learn why this is important

On 1/13/25 5:19 PM, 'Liang Zhao (REDMOND)' via blink-dev wrote:

Contact emails

lz...@microsoft.com


Explainer

None

 

I think an explainer (or even an inline text explaining the change, providing an example, etc) would have significantly helped folks understand what it is that you're trying to ship.

Could you write something to that effect?

 

When the url is blocked by Content Security Policy, script code “new Worker(url)” and “new SharedWorker(url)” currently throws exception. According to spec, the CSP check is done as part of fetch which happens asynchronously and the constructor should not throw. Instead an error event should fire after the object is returned.

This feature aligns Chromium behavior with spec.

 

This points at a relatively long algorithm. Can you point out the specific steps that are relevant here? 

 

Step 7 of the linked “main fetch” section. Updated the spec link in chromestatus to https://www.w3.org/TR/CSP3/#fetch-integration, which is a better place to understand that CSP check is part of fetch instead of details of how fetch is done in the fetch spec.




Summary

When blocked by CSP, Chromium currently throws SecurityError from constructor. Spec requires CSP to be checked as part of fetch and fires error event asynchronously. This aims to make Chromium spec conformant, which is not throwing during constructor and fires error event asynchronously.

Which constructor?

The constructor of Worker and SharedWorker objects. Also updated the chromestatus so that it is clear.

An example demonstrating where developers need to catch those exceptions now would be helpful IMO. 

 

Before the change if developer wants to handle the worker being blocked failure, the code would be something like this:

    try {

      var worker = new Worker(url);

      …

    } catch (e) {

     // error handling code

    }

After the change, the code would be something like this:

    var worker = new Worker(url);

    worker.addEventListener('error', function(event) {

        // error handling code

        });




Blink component

Blink>SecurityFeature>ContentSecurityPolicy


TAG review

None


TAG review status

Not applicable


Risks




Interoperability and Compatibility

Are you able to expand on the compatibility implications for this change, i.e., do we know if Firefox has any site breakage as a result of their behavior? What scenarios might surprise developers who are relying on Chrome's current behavior, etc?

 

We are not aware of any site breakage for Firefox due to its behavior. If a site has a worker that is blocked by CSP and has code after "new Worker()", those code currently does not run in Chrome or Safari, but runs in Firefox. After the change, those code would run in Chrome.

Also, if sites are doing something as a result of catching a CSP failure exception, that would stop working (unless they shift to start listening to the relevant event), right?

 

That is correct. If a site has code that runs upon catching SecurityError exception during new Worker()/SharedWorker(), those code would not run. Instead. if the site has error event listener, that event listener will run.

 

Currently Firefox works as spec-ed while Safari works the same as Chrome. With the wrong test code in WPT tests, Firefox is failing the tests: https://wpt.fyi/results/content-security-policy/worker-src/dedicated-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned https://wpt.fyi/results/content-security-policy/worker-src/shared-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned After updating Chrome code and WPT tests, Firefox passes the tests while Safari fails the tests.

Can you explain what you mean by wrong test code?

The current WPT test code expects exception to throw, which is not what’s required by the spec. The test code has a TODO comment states that the test code is wrong with a link to https://crbug.com/663298,



Gecko: Shipped/Shipping

WebKit: No signal

Have we asked for a signal from WebKit folks?

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Liang Zhao (REDMOND)

unread,
Jan 17, 2025, 1:28:09 PMJan 17
to Yoav Weiss (@Shopify), blink-dev, Chris Harrelson, Mike Taylor, blin...@chromium.org, Hiroshige Hayashizaki, Mike West

Got positive signal from Safari.

Positive signal from https://github.com/WebKit/standards-positions/issues/451: “As such I suggest we mark this as position: support one week from now.”

Mike Taylor

unread,
Jan 20, 2025, 7:48:38 AMJan 20
to Liang Zhao (REDMOND), Yoav Weiss (@Shopify), blink-dev, Chris Harrelson, Hiroshige Hayashizaki, Mike West

I'd still like to better understand the compat risk here - I suspect it's low, but I would not be surprised if there is code attempting to handle the difference between Chrome/Safari & Firefox with UA sniffing (which means it may break after this change).

Have you tried to look at any usage in the wild, to get a sense of how sites are dealing with CSP blocking a worker today?

Liang Zhao

unread,
Jan 21, 2025, 1:50:47 PMJan 21
to blink-dev, Mike Taylor, Chris Harrelson, Hiroshige Hayashizaki, Mike West, Liang Zhao (REDMOND), Yoav Weiss (@Shopify)
On Monday, January 20, 2025 at 4:48:38 AM UTC-8 Mike Taylor wrote:

I'd still like to better understand the compat risk here - I suspect it's low, but I would not be surprised if there is code attempting to handle the difference between Chrome/Safari & Firefox with UA sniffing (which means it may break after this change).

Have you tried to look at any usage in the wild, to get a sense of how sites are dealing with CSP blocking a worker today?

 The expected way to handle CSP blocking is to update CSP policy to allow the worker. Normally, a site’s own content security policy should not block its own workers. If a worker is blocked, the worker would not run and part of the site would be broken. The developer should update the site’s CSP policy to allow the worker. DevTools console message would clearly state that the worker is blocked by the site’s own CSP and CSP reporting feature allows site to detect the blocking of workers in the wild. Whether a worker runs should be more important to a site than the behavior when the worker is blocked. If a site cares about the blocking, it is expected that the site either updates its CSP to allow the worker, or removes the worker related code if the worker should not run. This is the main reason of my assessment of low compat risk. It is a behavior change when an error of a site's configuration has already caused bigger issue to the site.

I thought about collecting telemetry data and decided not to. We could collect counts of worker being blocked by CSP, but it would be hard to collect data on how a site might handle the blocking, like whether a site sniffs UA string and behaves differently, has a try-catch or has code to handle error event later if we don’t throw exception in constructor. As it is expected that it could happen that CSP blocks some workers, like during testing of a site, a raw count of the blocking would not help much on measuring the impact of this behavior change.

Mike Taylor

unread,
Jan 22, 2025, 4:20:52 AMJan 22
to Liang Zhao, blink-dev, Chris Harrelson, Hiroshige Hayashizaki, Mike West, Yoav Weiss (@Shopify)

In https://github.com/web-platform-tests/wpt/issues/41745#issuecomment-2377512723 - there's discussion of breakage on support.apple.com with this behavior, and Firefox developers mentions moving their behavior to align with Safari/Webkit given this breakage. The Bugzilla issue links to https://github.com/webcompat/web-bugs/issues/100874 and https://bugzilla.mozilla.org/show_bug.cgi?id=1927467.

Have you coordinated with Mozilla on this?

Reply all
Reply to author
Forward
0 new messages