I guess the reason is the new content security policy:
https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy

Quick and dirty solution:

1. Go to Jenkins Script Console at https://my-jenkins-server/script
2. Input

System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "")

3. Hit Run button

Better solution:

Read the article above and apply it

Hi Christian and thanks very much for your reply.

Something is very weird: I only managed to see the Javadoc after applying the specific fix for the Javadoc plugin( i.e., default-src 'none'; img-src 'self'; style-src 'self'; child-src 'self'; frame-src 'self' but NOT when completely disabling(unsetting) the header (i.e., System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "") as you yourself suggested).

Thanks again.

With the upcoming release you no longer need to disable security this way.

I'm sorry to say that this does not seem to work without the
JAVA_ARGS="$JAVA_ARGS -Dhudson.model.DirectoryBrowserSupport.CSP=\"default-src 'none'; img-src 'self'; style-src 'self'; child-src 'self'; frame-src 'self';\""
fix even with the newest version of the plugin using jenkins 1.651.3

Having Jenkins ver. 1.642.2 and Javadoc Plugin (Version 1.4 from Jun 17, 2016) installed - it still doesn't display the Javadoc contents.

What was referred to as "the upcoming release?" and what could be the problem?

Same thing here, cannot see the javadoc at all, and as I'm not the admin on my Jenkins instance, changing the JAVA_ARGS is not possible :/

have got the "javadoc does not load" issue too
I do get HTTP code 304 (not modified) in my FireFox web client - is this a HTTP client problem? When the web client cache is cleared, it works 1 time - then again not ...
Maybe it's not Jenkins alone but in conjunction with sitting in a Tomcat?
I'll check the HTTP headers further, maybe there's something wrong with 'em.

This is a bug in the configuration. See https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy

There is nothing to do at the plugin level.

The resolution of this bug is that as a workaround we open by default the non-framed page.

It does not work when there is just one package, because the attempted fix looked only for overview-summary.html, which is generated only when there are multiple packages. A refined fix could look for index-all.html, or overview-tree.html, or allclasses-noframe.html, or some */package-summary.html.

One workaround: use the more general Publish HTML plugin, for example:

publishHTML([reportDir: 'target/site/apidocs/', reportName: 'Javadoc', reportTitles: 'Javadoc', reportFiles: 'allclasses-noframe.html'])

To make this a bit more interesting, javadoc generated by Java 11 (likely Java9+) changes the behavior even further[1]:

• No frames by default (can be turned on but the feature is expected to go away).
• Dependency on javascript execution.
  • Redirect from index.html to single package-summary.html in case of single package project.
  • Framed navigation is replaced by JS-based search.
• It even appears, the <noscript> does not kick in when javascript is disables through CSP.

I went on exploring Jesse's suggestion of using different landing page on Javadoc 8 and 11 as well as using single/multi package projects. Both index-all.html and overview-tree.html appears to work (though subjectively, I am not sure this is the first page I would like to see) but allclasses-noframe.html is not generated on Java 11 (by default, at least).

[1] https://bugs.openjdk.java.net/browse/JDK-8202961

It even seems javadoc 11 redirects from overview-summary.html to index.html for multipackage projects while it redirects from index.html to the only package-summary.html available in case of singlepackage project. IOW, none of the locations is safe to use.

The **/package-summary.html can not be used as an index page either as it does not reside in the project root (obviously, it is summary of a java package) and therefore it refers to resources as ../../../foo.bar which obviously fails. In theory, this can be overcome by not using it as an index page for DirectoryBrowserSupport but modifying the JavadocAction too redirect to it instead so it is rendered at expected path.

I gave up decided to keep things simple and used overview-tree.html that is not ideal but prone of all those issues: https://github.com/jenkinsci/javadoc-plugin/pull/10

https://github.com/jenkinsci/javadoc-plugin/pull/10 needs to be released to close it

I have released 1.5 today which should integrate the recent reports

Wrong status in that case.