JDK-4366026 : HTMLEditorKit does not expose enough info about selected hyperlinks.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2000-08-25
  • Updated: 2000-11-27
  • Resolved: 2000-11-27
Related Reports
Duplicate :  

Name: ks88420			Date: 08/25/2000

java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

We need to have a non-frame anchor tag with additional attributes, e.g. <A
motive="www" method="xxx" href="yyy" target="zzz"> (perfectly valid HTML), and
retrieve those attributes from events received by our HyperLinkListener.

4109197 "Extensible HTML classes" asked for less of the HTMLEditorKit to be
package private.  The reply was that changes would be made to the API to expose

4182124 "HTMLEditorKit posting of ACTIVATE HyperlinkEvent()does not provide
enough info" gave an example of how <A HREF="http://www.klg.com" target="_new">
could not be handled because of the limited context of HyperLinkEvent.  The
posted solution proposed (1) to extend HyperLinkEvent to provide the offset of
the anchor, and (2) for frame documents, an extension HTMLFrameHyperlinkEvent
to also provide the contents of the target attribute.

Implementation status Status:
Referring to JDK 1.3.0 HTMLEditorKit v1.96, HyperlinkEvent v1.1.2, and
HTMLFrameHyperLinkEvent v1.4, one sees that (1) The offset was not put into
HyperlinkEvent, (2) Rather than an offset, the actual anchor Element was put
into HTMLFrameHyperLinkEvent, (3) createHyperlinkEvent(...) never calls the
constructor which sets that anchor Element field, and (4)
HTMLFrameHyperLinkEvents are only created if the HTML document is indeed a
frame document.

Design  & implementation problems:
The target="..." attribute is perfectly valid in non-frame documents ("_new" in
a browser will open up a new target frame, and so its use should not be
restricted to a frame document).  However due to point (3) we can only get the
target attribute's value for frame documents.  The getAnchor method is likewise
only defined for HTMLFrameHyperLinkEvent, not HyperLinkEvent (1 & 2), and
therefore other attributes cannot be obtained for non-frame anchors.

There could be a workaround if createHyperlinkEvent(...) could be subclassed,
but alas it is protected rather than package-private.

Proposed solutions for next release:
(a) Make createHyperlinkEvent(...) protected!!!
(b) Always emit an HTMLFrameHyperlinkEvent regardless of whether we are in a
frame or not (i.e. treat HyperlinkEvent as if it were an abstract base class).
(c) Fix createHyperlinkEvent(...) so it actually fills in the anchor element in
the HTMLFrameHyperlinkEvent (also whether or not in a frame).

Perhaps 15 changed lines of code, and I don't believe it will affect reverse-
compatility.  Can do?

Less important for us, but more complete as a solution, would be:
(d) Also the element offset to the event too, as originally proposed in the
answer to 4182124 (just don't remove the anchor Element itself!)
(Review ID: 107194) 

WORK AROUND Name: ks88420 Date: 08/25/2000 We can patch HTMLEditorKit.class to make createHyperlinkEvent protected, and implement the above changes ourself, but won't unless there's a commitment for it being fixed in the short term. ======================================================================

EVALUATION This has been addressed as part of 4182124. Refer to it for an updated description of how the code has changed to address this problem. scott.violet@eng 2000-11-27