This is caused by CSP blocking inline styles.

As a quick (maybe even final) fix we can change header to

header( 'Content-Security-Policy: default-src \'self\'; style-src \'self\' \'unsafe-inline\'' . $t_avatar_img_allow . '; frame-ancestors \'none\'' );

The curious thing is that it works in FF and Safari, but Safari shows the following new error in console after the change
[Error] Unrecognized Content-Security-Policy directive 'frame-ancestors'.
after the change

Hi Roland,

Thanks for your note.

I know it's CSP... In fact I initially did just what you proposed below, but for security reasons I'd rather avoid adding style-src 'self' as a permanent solution, although I suppose it could be OK as temporary workaround.

I started playing around with replacing the progress bar by a jQuery widget, which I think would be more elegant.

I started playing around with replacing the progress bar by a jQuery widget
We shouldn't start using JavaScript for standard functionality, at least not in 1.3.x.

I'd rather avoid adding style-src 'self' as a permanent solution
I thought that 'unsafe-inline' fixed it.

I thought that 'unsafe-inline' fixed it.

Sorry, that's what I meant.

We shouldn't start using JavaScript for standard functionality, at least not in 1.3.x.

Why not ? I mean, we are bundling jQuery/jQueryUI... what's the point if we then refrain from using it ?

EDIT: As a side note, I can't think of any way to achieve the colored progress bar without using inline style or javascript. If you have any ideas let me know.

I thought about this some more, and I think that it is an acceptable risk to selectively enable inline styles for the roadmap page only, as a temporary workaround for this issue. We can revisit this later on.

I'm still interested in hearing your opinion on use of jQuery though, but maybe the mailing list is a better channel for that discussion.

I can't think of any way to achieve the colored progress bar without using inline style or javascript. If you have any ideas let me know.

Doing it the same way we are handling status colors should work (css/status_config.php)

The problem with this approach, is that while the CSS is dynamically generated, it is still static from the perspective of the page using it, i.e. the classes are defined once when the DCSS is included. In the case of the progress bars, we are setting their width at run time.

So, following this approach, the php script would have to generate 101 distinct CSS classes (one per percentage point), e.g. width0, width1, width2, etc until width100, to define all possible widths. That's easy enough, but not very efficient.

You are right.
I forgot for a moment that there is more than one product with more than one version.
101 classes are not needed, the distinct % values of all versions would be enough.
But we would have to calculate all precent values before we start building the page.

the php script would have to generate 101 distinct CSS classes
In this case we could also use a static CSS with 101 classes.
At least this would be a bit more efficient than generating it on the fly.

TBH, I like none of both approaches.

Another approach could be to use HTML5 canvas or SVG.
Cerainly not worth to think about in 1.3.x.

Why not ? I mean, we are bundling jQuery/jQueryUI
JavaScript has not been used for any standard functionality until now.
I think that having a wrong roadmap percentage display is a curious side effect of disabled JavaScript and not acceptable.

I have personally no problem to require JavaScript to run MantisBT.
I think we had this discussion a while ago and agreed to enforce it in 2.0.

Maybe we have even to enforce it in 1.3.x as there is at least one regression when disabling JavaScript, see 0019508.