Re: Strict CSP (nonce + strict-dynamic) with GWT – CSP violation from code-splitting

Hi Thomas,

Thanks for the clarification. The FormPanel you referred to is the GWT core one
(com.google.gwt.user.client.ui.FormPanel), which I understand has been CSP-compliant (using about:blank).

In our case, the issue is coming from Sencha GXT's FormPanel
(com.sencha.gxt.widget.core.client.form.FormPanel), which internally still creates a hidden iframe with src="javascript:''".

This iframe creation is what triggers the remaining CSP console error under a strict nonce + strict-dynamic policy.

Just wanted to clarify that the issue is specific to GXT

On Monday, 2 February 2026 at 22:16:44 UTC+5:30 Thomas Broyer wrote:

Fwiw, GWT's own FormPanel has been using about:blank rather than javascript:'' for nearly 9 years specifically for Strict CSP compliance: https://github.com/gwtproject/gwt/commit/05091ff95a904b42246f5d9b90b6ae362c1bb5fb

On Monday, February 2, 2026 at 12:39:49 PM UTC+1 garim...@gmail.com wrote:

Hi Craig, thanks for the response.

Yes, I tried the custom linker approach (GWT 2.12 + linker extending CrossSiteIframeLinker) earlier But my issue is not related to linker. GWT code splitting and script loading work correctly with nonce + strict-dynamic.

After further debugging, I realized the remaining CSP error is not coming from GWT's linker or code splitting mechanism itself, but from Sencha GXT, specifically com.sencha.gxt.widget.core.client.form.FormPanel.

Using DOM inspection and a MutationObserver, I confirmed that FormPanel internally creates hidden iframes like:

<iframe src="javascript:''" ...>

This triggers the CSP console error under strict policies, even though the application functions correctly and all APIs return 200.

Now I want to confirm if there is any supported or tested way in GWT/GXT to:

• Prevent FormPanel from using iframe src="javascript:''", or

• Override/patch this behavior in a CSP-compliant way

Thanks

On Friday, 30 January 2026 at 11:48:04 UTC+5:30 Craig Mitchell wrote:

I haven't faced this issue.  My GWT code splitting works fine, but maybe I haven't turned on all the content security policies.

You did ask this question before, and there was a suggestion to use a custom linker:  https://groups.google.com/g/google-web-toolkit/c/rzAAIIZxGUY/m/rDDPSDMQCAAJ

On Friday, 30 January 2026 at 4:20:11 pm UTC+11 Garima Jain wrote:

Hi everyone,

Following up to check if anyone has faced a similar issue with classic GWT and strict CSP.

The application works correctly with a nonce-based CSP and strict-dynamic, but a CSP console error still appears during GWT code splitting (runAsync), when split fragments (e.g., application-0.js) are executed via runtime javascript: URLs.

Error:

application-0.js:1835 Running the JavaScript URL violates the following Content Security Policy directive 'script-src 'self' 'nonce-kq/FBq3JY1ktQIm9FMZoYw==' 'strict-dynamic' 'unsafe-eval''. Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. The action has been blocked.

If anyone has successfully resolved this CSP error (without relaxing CSP by adding unsafe-inline), I'd really appreciate it if you could share the approach or workaround you used.

Thanks in advance!

On Monday, 26 January 2026 at 14:23:12 UTC+5:30 Garima Jain wrote:

Hi,

I'm working on a classic GWT application and trying to apply a strict Content Security Policy (CSP) using a nonce generated per request.

CSP Using:

default-src 'self'; script-src 'self' 'nonce-<dynamic>' 'strict-dynamic' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; object-src 'self'; img-src 'self' data:;

What's working:

• The app loads and runs correctly.

• GWT is able to load its scripts dynamically.

• The iframe now uses a safe URL (about:blank) instead of a javascript: URL and works with the current CSP.  

• No functional issues in the app.

What's the problem:
Even though everything works, the browser console shows this error:

Running the JavaScript URL violates the Content Security Policy directive

The stack trace originates from GWT code-splitting (runAsync), specifically during execution of split fragments (e.g., application-0.js).
This appears to involve runtime JavaScript execution via javascript: URLs, which is blocked under strict CSP.

My questions:

1. Is there a supported way in GWT to avoid this javascript: execution when using code splitting?

2.   Is this console error considered a known limitation of classic GWT under strict CSP, and acceptable if the application works correctly?  

I'd like to keep CSP strict and avoid adding unsafe-inline.

Thanks!

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/9861c82e-70df-4158-95d3-80bcf33b3c2en%40googlegroups.com.

IRe: GWT 2.11 compiler option -includeJsInteropExports gives an error

I'm sorry, I cannot confirm. I just tested by downloading the gwt-2.11.0.zip, and editing the Hello sample included to have a new JsMethod. Then I edited the "gwtc" target in the sample's build.xml by adding generateJsInteropExports and a _deliberately wrong_ expression for -includeJsInteropExports, and confirmed that the method was not exported. Then I changed the pattern to one that made sense, ran the compiler again, and confirmed that I could access the simple method.

Can you please share a simple example of what exactly isn't working? The Hello sample included in the SDK for 2.11 uses ant, so this isn't likely a build tool issue - you should be able to reproduce it there and share the complete project that isn't working.

On Monday, February 2, 2026 at 5:53:36 PM UTC-6 chakl...@gmail.com wrote:

Both DevMode/codeserver and gwtc do not work in GWT 2.11.

When passing the argument to the codeserver, it get the error and won't start.

When passing the argument to compiler (using Ant), it compiles but the JsInteropExports is missing.

Thanks. 

On Monday, February 2, 2026 at 12:35:07 PM UTC-5 Colin Alworth wrote:

Note that the linked issue and fix is specific to running DevMode, not the compiler itself, but you seem to be having issues with the compiler?

On Monday, February 2, 2026 at 11:03:27 AM UTC-6 chakl...@gmail.com wrote:

Just found out that the bug fix is merged to 2.12

https://github.com/gwtproject/gwt/issues/9939

I guess I will try it when I migrate my application to GWT 2.12

Thanks.

On Friday, January 30, 2026 at 7:09:40 PM UTC-5 Craig Mitchell wrote:

Are you using the gwt-maven-plugin?

I think you'd do it something like this:

<compilerArgs>

  <arg>-generateJsInteropExports</arg>

  <arg>-includeJsInteropExports</arg>

  <arg>com.nyct.client.ui.widget.StreetMap.north</arg>

</compilerArgs>

On Saturday, 31 January 2026 at 10:22:30 am UTC+11 Chak Lai wrote:

Hi,

I am trying to include compiler option -includeJsInteropExports in GWT 2.11, but it gives me an error.

Here is my parameters

-generateJsInteropExports

-includeJsInteropExports com.nyct.client.ui.widget.StreetMap.north

Error:

-includeJsInteropExports regex cannot start with '+' or '-'

Note:

com.nyct.client.ui.widget.StreetMap.north is a method in my object.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/7ff8e76d-9eae-48b4-9cdb-9ff3d33dec83n%40googlegroups.com.

Re: GWT 2.11 compiler option -includeJsInteropExports gives an error

Both DevMode/codeserver and gwtc do not work in GWT 2.11.

When passing the argument to the codeserver, it get the error and won't start.

When passing the argument to compiler (using Ant), it compiles but the JsInteropExports is missing.

Thanks. 

On Monday, February 2, 2026 at 12:35:07 PM UTC-5 Colin Alworth wrote:

Note that the linked issue and fix is specific to running DevMode, not the compiler itself, but you seem to be having issues with the compiler?

On Monday, February 2, 2026 at 11:03:27 AM UTC-6 chakl...@gmail.com wrote:

Just found out that the bug fix is merged to 2.12

https://github.com/gwtproject/gwt/issues/9939

I guess I will try it when I migrate my application to GWT 2.12

Thanks.

On Friday, January 30, 2026 at 7:09:40 PM UTC-5 Craig Mitchell wrote:

Are you using the gwt-maven-plugin?

I think you'd do it something like this:

<compilerArgs>

  <arg>-generateJsInteropExports</arg>

  <arg>-includeJsInteropExports</arg>

  <arg>com.nyct.client.ui.widget.StreetMap.north</arg>

</compilerArgs>

On Saturday, 31 January 2026 at 10:22:30 am UTC+11 Chak Lai wrote:

Hi,

I am trying to include compiler option -includeJsInteropExports in GWT 2.11, but it gives me an error.

Here is my parameters

-generateJsInteropExports

-includeJsInteropExports com.nyct.client.ui.widget.StreetMap.north

Error:

-includeJsInteropExports regex cannot start with '+' or '-'

Note:

com.nyct.client.ui.widget.StreetMap.north is a method in my object.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/8f51e404-16be-4b9a-9e2a-ab2245900f3dn%40googlegroups.com.

Re: GWT 2.11 compiler option -includeJsInteropExports gives an error

Note that the linked issue and fix is specific to running DevMode, not the compiler itself, but you seem to be having issues with the compiler?

On Monday, February 2, 2026 at 11:03:27 AM UTC-6 chakl...@gmail.com wrote:

Just found out that the bug fix is merged to 2.12

https://github.com/gwtproject/gwt/issues/9939

I guess I will try it when I migrate my application to GWT 2.12

Thanks.

On Friday, January 30, 2026 at 7:09:40 PM UTC-5 Craig Mitchell wrote:

Are you using the gwt-maven-plugin?

I think you'd do it something like this:

<compilerArgs>

  <arg>-generateJsInteropExports</arg>

  <arg>-includeJsInteropExports</arg>

  <arg>com.nyct.client.ui.widget.StreetMap.north</arg>

</compilerArgs>

On Saturday, 31 January 2026 at 10:22:30 am UTC+11 Chak Lai wrote:

Hi,

I am trying to include compiler option -includeJsInteropExports in GWT 2.11, but it gives me an error.

Here is my parameters

-generateJsInteropExports

-includeJsInteropExports com.nyct.client.ui.widget.StreetMap.north

Error:

-includeJsInteropExports regex cannot start with '+' or '-'

Note:

com.nyct.client.ui.widget.StreetMap.north is a method in my object.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/aa74bd2c-3eb9-42f0-bd8d-71ebbff6a7b1n%40googlegroups.com.

Re: GWT 2.11 compiler option -includeJsInteropExports gives an error

Just found out that the bug fix is merged to 2.12

https://github.com/gwtproject/gwt/issues/9939

I guess I will try it when I migrate my application to GWT 2.12

Thanks.

On Friday, January 30, 2026 at 7:09:40 PM UTC-5 Craig Mitchell wrote:

Are you using the gwt-maven-plugin?

I think you'd do it something like this:

<compilerArgs>

  <arg>-generateJsInteropExports</arg>

  <arg>-includeJsInteropExports</arg>

  <arg>com.nyct.client.ui.widget.StreetMap.north</arg>

</compilerArgs>

On Saturday, 31 January 2026 at 10:22:30 am UTC+11 Chak Lai wrote:

Hi,

I am trying to include compiler option -includeJsInteropExports in GWT 2.11, but it gives me an error.

Here is my parameters

-generateJsInteropExports

-includeJsInteropExports com.nyct.client.ui.widget.StreetMap.north

Error:

-includeJsInteropExports regex cannot start with '+' or '-'

Note:

com.nyct.client.ui.widget.StreetMap.north is a method in my object.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/e1e23f6c-c366-4daf-a97b-68f64e73fc57n%40googlegroups.com.

Re: Strict CSP (nonce + strict-dynamic) with GWT – CSP violation from code-splitting

Fwiw, GWT's own FormPanel has been using about:blank rather than javascript:'' for nearly 9 years specifically for Strict CSP compliance: https://github.com/gwtproject/gwt/commit/05091ff95a904b42246f5d9b90b6ae362c1bb5fb

On Monday, February 2, 2026 at 12:39:49 PM UTC+1 garim...@gmail.com wrote:

Hi Craig, thanks for the response.

Yes, I tried the custom linker approach (GWT 2.12 + linker extending CrossSiteIframeLinker) earlier But my issue is not related to linker. GWT code splitting and script loading work correctly with nonce + strict-dynamic.

After further debugging, I realized the remaining CSP error is not coming from GWT's linker or code splitting mechanism itself, but from Sencha GXT, specifically com.sencha.gxt.widget.core.client.form.FormPanel.

Using DOM inspection and a MutationObserver, I confirmed that FormPanel internally creates hidden iframes like:

<iframe src="javascript:''" ...>

This triggers the CSP console error under strict policies, even though the application functions correctly and all APIs return 200.

Now I want to confirm if there is any supported or tested way in GWT/GXT to:

• Prevent FormPanel from using iframe src="javascript:''", or

• Override/patch this behavior in a CSP-compliant way

Thanks

On Friday, 30 January 2026 at 11:48:04 UTC+5:30 Craig Mitchell wrote:

I haven't faced this issue.  My GWT code splitting works fine, but maybe I haven't turned on all the content security policies.

You did ask this question before, and there was a suggestion to use a custom linker:  https://groups.google.com/g/google-web-toolkit/c/rzAAIIZxGUY/m/rDDPSDMQCAAJ

On Friday, 30 January 2026 at 4:20:11 pm UTC+11 Garima Jain wrote:

Hi everyone,

Following up to check if anyone has faced a similar issue with classic GWT and strict CSP.

The application works correctly with a nonce-based CSP and strict-dynamic, but a CSP console error still appears during GWT code splitting (runAsync), when split fragments (e.g., application-0.js) are executed via runtime javascript: URLs.

Error:

application-0.js:1835 Running the JavaScript URL violates the following Content Security Policy directive 'script-src 'self' 'nonce-kq/FBq3JY1ktQIm9FMZoYw==' 'strict-dynamic' 'unsafe-eval''. Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. The action has been blocked.

If anyone has successfully resolved this CSP error (without relaxing CSP by adding unsafe-inline), I'd really appreciate it if you could share the approach or workaround you used.

Thanks in advance!

On Monday, 26 January 2026 at 14:23:12 UTC+5:30 Garima Jain wrote:

Hi,

I'm working on a classic GWT application and trying to apply a strict Content Security Policy (CSP) using a nonce generated per request.

CSP Using:

default-src 'self'; script-src 'self' 'nonce-<dynamic>' 'strict-dynamic' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; object-src 'self'; img-src 'self' data:;

What's working:

• The app loads and runs correctly.

• GWT is able to load its scripts dynamically.

• The iframe now uses a safe URL (about:blank) instead of a javascript: URL and works with the current CSP.  

• No functional issues in the app.

What's the problem:
Even though everything works, the browser console shows this error:

Running the JavaScript URL violates the Content Security Policy directive

The stack trace originates from GWT code-splitting (runAsync), specifically during execution of split fragments (e.g., application-0.js).
This appears to involve runtime JavaScript execution via javascript: URLs, which is blocked under strict CSP.

My questions:

1. Is there a supported way in GWT to avoid this javascript: execution when using code splitting?

2.   Is this console error considered a known limitation of classic GWT under strict CSP, and acceptable if the application works correctly?  

I'd like to keep CSP strict and avoid adding unsafe-inline.

Thanks!

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/a8a0813c-de87-411a-8049-4844987c7709n%40googlegroups.com.

Re: Strict CSP (nonce + strict-dynamic) with GWT – CSP violation from code-splitting

Isn't there a hash mentioned in the errorlog that you can add to the CSP?

Op maandag 2 februari 2026 om 12:39:49 UTC+1 schreef Garima Jain:

Hi Craig, thanks for the response.

Yes, I tried the custom linker approach (GWT 2.12 + linker extending CrossSiteIframeLinker) earlier But my issue is not related to linker. GWT code splitting and script loading work correctly with nonce + strict-dynamic.

After further debugging, I realized the remaining CSP error is not coming from GWT's linker or code splitting mechanism itself, but from Sencha GXT, specifically com.sencha.gxt.widget.core.client.form.FormPanel.

Using DOM inspection and a MutationObserver, I confirmed that FormPanel internally creates hidden iframes like:

<iframe src="javascript:''" ...>

This triggers the CSP console error under strict policies, even though the application functions correctly and all APIs return 200.

Now I want to confirm if there is any supported or tested way in GWT/GXT to:

• Prevent FormPanel from using iframe src="javascript:''", or

• Override/patch this behavior in a CSP-compliant way

Thanks

On Friday, 30 January 2026 at 11:48:04 UTC+5:30 Craig Mitchell wrote:

I haven't faced this issue.  My GWT code splitting works fine, but maybe I haven't turned on all the content security policies.

You did ask this question before, and there was a suggestion to use a custom linker:  https://groups.google.com/g/google-web-toolkit/c/rzAAIIZxGUY/m/rDDPSDMQCAAJ

On Friday, 30 January 2026 at 4:20:11 pm UTC+11 Garima Jain wrote:

Hi everyone,

Following up to check if anyone has faced a similar issue with classic GWT and strict CSP.

The application works correctly with a nonce-based CSP and strict-dynamic, but a CSP console error still appears during GWT code splitting (runAsync), when split fragments (e.g., application-0.js) are executed via runtime javascript: URLs.

Error:

application-0.js:1835 Running the JavaScript URL violates the following Content Security Policy directive 'script-src 'self' 'nonce-kq/FBq3JY1ktQIm9FMZoYw==' 'strict-dynamic' 'unsafe-eval''. Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. The action has been blocked.

If anyone has successfully resolved this CSP error (without relaxing CSP by adding unsafe-inline), I'd really appreciate it if you could share the approach or workaround you used.

Thanks in advance!

On Monday, 26 January 2026 at 14:23:12 UTC+5:30 Garima Jain wrote:

Hi,

I'm working on a classic GWT application and trying to apply a strict Content Security Policy (CSP) using a nonce generated per request.

CSP Using:

default-src 'self'; script-src 'self' 'nonce-<dynamic>' 'strict-dynamic' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; object-src 'self'; img-src 'self' data:;

What's working:

• The app loads and runs correctly.

• GWT is able to load its scripts dynamically.

• The iframe now uses a safe URL (about:blank) instead of a javascript: URL and works with the current CSP.  

• No functional issues in the app.

What's the problem:
Even though everything works, the browser console shows this error:

Running the JavaScript URL violates the Content Security Policy directive

The stack trace originates from GWT code-splitting (runAsync), specifically during execution of split fragments (e.g., application-0.js).
This appears to involve runtime JavaScript execution via javascript: URLs, which is blocked under strict CSP.

My questions:

1. Is there a supported way in GWT to avoid this javascript: execution when using code splitting?

2.   Is this console error considered a known limitation of classic GWT under strict CSP, and acceptable if the application works correctly?  

I'd like to keep CSP strict and avoid adding unsafe-inline.

Thanks!

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/9c5326a4-65fc-4c69-9752-560a78a28a5cn%40googlegroups.com.