It is a security issue with recent versions of Jenkins. We upgraded the ImageJ Jenkins yesterday, which caused us to become affected by the issue.
I have now instituted a configuration change on the server side to avoid the issue.
You may need to force refresh (e.g., Shift+F5 or Shift+Ctrl+R) to see the javadoc again.
From the Jenkins Configuring Content Security Policy page:
Jenkins 1.641 / Jenkins 1.625.3 introduce the
Content-Security-Policy header to static files served by Jenkins (specifically,
DirectoryBrowserSupport). This header is set to a very restrictive default set of permissions to protect Jenkins users from malicious HTML/JS files in workspaces,
/userContent, or archived artifacts.
Unfortunately, several popular, useful plugins are affected by this and lose part of their functionality unless the default rules are relaxed.
The Javadoc Plugin makes Javadoc available for browsing in Jenkins. The default rule set does not allow use of frames in pages served by Jenkins. To make this work again, the directives
frame-src 'self' and child-src 'self' must be added to the CSP header. It appears Safari also requires the
sandbox directive to be removed.
default-src 'none'; img-src 'self'; style-src 'self'; child-src 'self'; frame-src 'self';
The ImageJ Jenkins now applies this fix via
/etc/default/jenkins which includes the line:
JAVA_ARGS="$JAVA_ARGS -Dhudson.model.DirectoryBrowserSupport.CSP=\"default-src 'none'; img-src 'self'; style-src 'self'; child-src 'self'; frame-src 'self';\""
Without this change, Javadoc pages served by Jenkins are blank, e.g. with Chrome reporting:
Blocked script execution in ‘http://jenkins.imagej.net/job/ImageJ-javadoc/javadoc/’ because the document’s frame is sandboxed and the ‘allow-scripts’ permission is not set.
Note that other recently upgraded Jenkins systems, such as the OME Jenkins, also suffer from this problem (at the time of this writing).