HTMLEditorKit.create() cannot handle element types that do not set the name attribute using StyleConstants.NameAttribute. As a result, methods like JTextPane.insertComponent() do not work properly with an HTMLEditorKit.

The problem is that AbstractDocument and StyledEditorKit use AbstractDocument.ElementNameAttribute to represent the element name and HTMLDocument and HTMLEditorKit use StyleConstants.NameAttribute.

When HTMLEditorKit then calls getAttribute(StyleConstants.NameAttribute) and the name is not defined, the attribute resolves upwards to the parent until if finds something (ie. the wrong element type).

You can see this behavior with the attached test case. Compile and run ComponentTest.java. Hitting the button on top should insert components into the JTextPane. Instead, blank space is inserted. Hitting the button at the bottom brings up a tree showing the view structure. Notice that javax.swing.text.html.ParagraphViews are being created where the ComponentViews should be.

Additional note:
I suspect the fix to this will involve changes to HTMLEditorKit.create() so I am making a note of something else that should change there. This is not causing the bad behavior described in the bug report but may when the bug is fixed.

Lines 1153 and 1154 read:

} else if (nm.equals(AbstractDocument.ParagraphElementName)) {
    return new ParagraphView(elem);
}

I beleive this should create a new java.swing.text.ParagraphView instead.

N/A

(  xxxxx@xxxxx  )

The reason of the bug is the following: The problem is that AbstractDocument and 
StyledEditorKit use
AbstractDocument.ElementNameAttribute to represent the element name and
HTMLDocument and HTMLEditorKit use StyleConstants.NameAttribute.
When HTMLEditorKit then calls getAttribute(StyleConstants.NameAttribute) and
the name is not defined, the attribute resolves upwards to the parent until if
finds something (ie. the wrong element type).
The idea of suggested fix is to try to get AbstractDocument.ElementNameAttribute
first and if it is null then to get StyleConstants.NameAttribute.
Since elements named with AbstractDocument.ElementNameAttribute
are only leaf elements fix shouldn't cause situation
when ElementNameAttribute is not defined and attribute resolves upwards to the 
parent until it
finds something.

======================================================================





The previous evaluation by   xxxxx@xxxxx   is thorough and
correct.

  xxxxx@xxxxx   2004-03-24




======================================================================

Anyone know of a workaround for this?