[
https://issues.apache.org/jira/browse/XERCESJ-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Glavassevich reassigned XERCESJ-1597:
---------------------------------------------
Assignee: Michael Glavassevich
> document.cloneNode() copies identifiers map but fails to apply IDness to
> relevant attribute nodes
> -------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1597
> URL: https://issues.apache.org/jira/browse/XERCESJ-1597
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Affects Versions: 2.11.0
> Environment: Java in any environment
> Reporter: Jacob Kjome
> Assignee: Michael Glavassevich
> Labels: patch
> Attachments: CoreDocumentImpl.java_CloningDoc_IDness.patch
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> What the latest Xerces2 DOM does with attribute ID'ness upon cloning a
> document is to copy over the map of identifiers. This allows
> document.getElementById(String) [1] to work. But the attribute node(s) in
> question will still return 'false' in response to attr.isId() [2]. What it
> fails to do is call element.setIdAttributeNode(Attr,boolean) [3].
> This leads to quirky behavior in the cloned document when removing an
> attribute from an element that has a corresponding entry in the identifiers
> map, because removeAttribute(String) does an internal check for ID'ness to
> see if it should clean up the identifiers map. But because the attribute
> node reports itself as NOT of type "ID", this cleanup is skipped, causing
> document.getElementById(String) [3] to continue returning the element [from
> the identifiers map] even after attribute removal.
> I've actually modified the Xerces2 CoreDocumentImpl class to correct this
> behavior in a way that actually cleans up quite a bit of code. Patch coming
> up shortly. I'd appreciate if someone could review it.
> For users working with cloned documents and are running into this issue,
> there is a workaround. Prior to removing an attribute (let's say "id" in the
> HTML DOM) which currently provides an element upon
> document.getElementById("myIdName"), perform the following call...
> element.setIdAttribute("id", true);
> With that set, the check check for IDness within the call to
> element.removeAttribute("id") will succeed and, therefore, clean up the
> corresponding entry in the identifiers map. Now further calls to
> document.getElementById("myIdName") will produce "null", as expected. This
> workaround will also continue to work after the patch is applied, though it
> will no longer be necessary.
> [1]
> http://xerces.apache.org/xerces2-j/javadocs/api/org/w3c/dom/Document.html#getElementById(java.lang.String)
> [2]
> http://xerces.apache.org/xerces2-j/javadocs/api/org/w3c/dom/Attr.html#isId()
> [3]
> http://xerces.apache.org/xerces2-j/javadocs/api/org/w3c/dom/Element.html#setIdAttributeNode(org.w3c.dom.Attr,%20boolean)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
