[
https://issues.apache.org/jira/browse/XERCESJ-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Kjome updated XERCESJ-1597:
---------------------------------
Attachment: CoreDocumentImpl.java_CloningDoc_IDness.patch
Applies IDness to relevant attributes when cloning documents. And since using
element.setIdAttributeNode(attr, true) automatically manages the identifiers
map,it was possible to extricate usage of the "reverseIdentifiers" map. This
makes the code quite a bit cleaner. It also avoids blindly copying identifiers
regardless of whether we're cloning a document or just one element within a
document. It seems to me it was a bug do do that in the first place, at least
according to XERCESJ-1022 .
I officially contribute this patch to the Xerces project. I hope it can be
part of the next official release.
> 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
> 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]
