So, to clarify, there are two parts to this:
- The HTML Publisher surrounds the published pages with a frame linking to the configured index pages. This frame was broken in 1.625.3/1.641, and the plugin release 1.10 fixes this.
- The published HTML pages may not display correctly when using things like XHR, JavaScript, inline CSS, etc. This is by design and was one of the security fixes in 1.625.3/1.641.
To work around the second issue, you basically have the following options with this:
- Live with the brokenness, if it's not too severe. (E.g. Javadoc plugin has a similar issue with Javascript not running even with PR 4 applied), but it's hardly noticeable in my testing.
- Publish the HTML pages elsewhere and just link there from Jenkins.
- Make the HTML pages work without this kind of dynamic content or adapt to work within the rules (e.g. external CSS files rather than inline).
- Relax the rules controlling what static HTML files served by Jenkins are allowed to do: See documentation.
You may be asking "Daniel, this security issue seems a bit far-fetched – most installations allow everyone to do everything, why so restrictive?" Good point. Unfortunately, while many, possibly most, Jenkins installations may not need this protection because it's not a threat to them, given how many users don't bother to apply basic common sense to their instance security, we opted to make Jenkins secure out of the box in this regard, rather than make it opt-in.
I'm seeing the same issue:
and I believe it may be related to iframe permissions. I only see the error in a Jenkins instance answering HTTPS, with multiple console messages:
Blocked script execution in 'https://my.jenkins.redacted/jenkins/view/Project/job/job_name/Test_Summaries/' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.