JDK-8209914 : javadoc search sometimes generates bad URIs
  • Type: Bug
  • Component: tools
  • Sub-Component: javadoc(tool)
  • Affected Version: 9,10,11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-08-23
  • Updated: 2020-01-13
  • Resolved: 2018-09-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12
11.0.4-oracleFixed 12 b12Fixed
Related Reports
Duplicate :  
JDK-8207931 - Javadoc search result depends on where you click with your mouse
Relates :  
JDK-8214468 - jQuery UI upgrade from 1.11.4 to 1.12.1
Description
The following is a report from Alex B.

Browser: Firefox 60.1.0esr (32-bit) on Windows 7 SP1 (OBI)

1. Visit https://download.java.net/java/early_access/jdk11/docs/api/

2. Search `List.of` and pick `java.util.List.of(E)` from dropdown.

3. Browser jumps correctly to https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/util/List.html#of(E) -- see attached screenshot.

4. On that page, search `List.of` again, and pick `java.util.List.of(E,E,E,E,E,E,E,E,E,E)` from dropdown (the first heavily overloaded method, with 10 parameters).

5. Browser jumps incorrectly to https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/util/List.html# -- see attached screenshot.

Alex
Comments
Fix Request (11u) Backporting fixes a small bug in javadoc, and keeps codebases in sync between releases (I see 11.0.4-oracle). Patch applies cleanly to 11u and passes tier1 tests.
16-04-2019
The problem actually occurs on all browsers I have tried (Safari, Firefox, Chrome on variouis platforms) but only under very specifc conditions, which explains the confusion about reproducibility and platform dependency. The problem occurs if: - the link is an anchor on the current page - the link is followed via mouse click (as opposed to hitting the enter key) - the mouse is clicked on the text of the entry (not the blank space after the text) It is caused by search suggestions being wrapped in a <a> element with href="#" attribute. This does not come into effect if the link is to a different HTML page, but if the link is to an anchor in the current page it overrides the anchor targeted via JavaScript (the browser moves to the correct anchor first and to the top of the page immediately afterwards). The suggested fix is to remove the <a href="#"> element. It is not needed as the autocomplete widget is fully implemented in JS/CSS. Webrev: http://cr.openjdk.java.net/~hannesw/8209914/webrev.00/ API docs generated with patched JDK: http://cr.openjdk.java.net/~hannesw/8209914/api/
05-09-2018
FYI - the bug is also reproducible on macOS / Firefox.
04-09-2018
1. The problem does not seem to occur on macOS/Safari or Ubuntu/firefox. 2. Note the invalid URL (ending in # with no fragment) in the URL bar. >> This might indicate a problem in the JavaScript to determine the URL. 3. Alex also noted the problem was "modal" in that the bug seemed to be sticky on a page ... if you go away and revisit the page, the search would work again: put another way: when searching for an instance of a heavily overloaded method, the first one seems to work; follow-up searches on the same page show the described problem. >> This might indicate a problem with JavaScript incorrectly using some saved state, which gets reset when going to another page and back.
23-08-2018