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 [email protected] 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/9861c82e-70df-4158-95d3-80bcf33b3c2en%40googlegroups.com.
