[jira] [Updated] (XERCESJ-1597) document.cloneNode() copies identifiers map but fails to apply IDness to relevant attribute nodes

["Jacob Kjome (JIRA)" <xe...@xml.apache.org>]

     [ 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org