Active
Project:
Drupal core
Version:
main
Component:
CSS
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
4 Sep 2025 at 10:50 UTC
Updated:
19 Dec 2025 at 17:43 UTC
Jump to comment: Most recent, Most recent file


Comments
Comment #2
quietone commentedHi, If this problem was discovered on a version of Drupal that is not 11.x, add that information in the issue summary and leave the version at 11.x. In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies. Thanks.
Comment #3
dpiComment #4
dpiComment #5
angel_devoeted commentedHi, thanks for sharing this.
The described behavior makes sense with strict CSP. Before discussing a specific resolution, I think it would be helpful to clarify whether strict CSP compatibility for the progress bar is considered in scope for core, given that it’s primarily used in admin/batch contexts where CSP is often excluded.
Comment #6
longwaveOne fix would be to convert the progress bar to use the
<progress>element?https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/pro...
#1477550: Bring progressbar to the postmodern era is somewhat dated but also suggests that as an option.
Comment #7
dpiIf there is any place CSP should be on above all others, is when a user with privileged access is authenticated.
For the CSP module, there is no delineation between roles or front/admin theme. Its either on, in reporting mode, or off: globally.
Drupal should aim for as strict as possible compliance, though it hasnt been prioritized as far as I know. Besides, the problem at hand, inline styles and script, are also not best practice either.