You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Michael Glavassevich (JIRA)" <xe...@xml.apache.org> on 2012/12/06 20:51:09 UTC
[jira] [Assigned] (XERCESJ-1597) document.cloneNode() copies
identifiers map but fails to apply IDness to relevant attribute nodes
[ 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org