[
https://issues.apache.org/jira/browse/XERCESJ-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated XERCESJ-1801:
-------------------------------------------
Description:
see thread on https://github.com/apache/xerces-j/pull/96/changes#r3914030798
According to the DOM Level 3 Core specification, replacing this node is
strictly expected to fail and raise a NO_MODIFICATION_ALLOWED_ERR. Because
entities=true is set earlier, the logically adjacent EntityReference node
(&ent5;) is expanded as read-only. We should likely revert this specific check
to a try-catch asserting the DOMException, otherwise the test loses its ability
to enforce the W3C spec compliance here. ->
https://www.w3.org/TR/DOM-Level-3-Core/core.html#Text3-replaceWholeText
This seems to be an edge case with the nested entity this test wanted to cover.
Why Xerces fails to throw it (TextImpl.java): To validate the replacement,
TextImpl calls canModifyNext(Node). When it encounters a nested entity, it
recursively calls canModifyNext:
1. canModifyNext("Test: ")
2. Iterates to adjacent entity &ent5;
3. Iterates over children of &ent5; and hits nested entity &ent6;
4. Recursively calls canModifyNext(&ent6;)
5. The Bug: canModifyNext(node) immediately calls node.getNextSibling(). As a
result, it skips checking the children of &ent6;, completely missing the <foo/>
element.
See testWholeText in tests/dom/dom3/Test.java
The behavior the test tests for and that Xerces currenlty implements is likely
incorrect per spec
was:
see thread on https://github.com/apache/xerces-j/pull/96/changes#r3914030798
According to the DOM Level 3 Core specification, replacing this node is
strictly expected to fail and raise a NO_MODIFICATION_ALLOWED_ERR. Because
entities=true is set earlier, the logically adjacent EntityReference node
(&ent5;) is expanded as read-only. We should likely revert this specific check
to a try-catch asserting the DOMException, otherwise the test loses its ability
to enforce the W3C spec compliance here. ->
https://www.w3.org/TR/DOM-Level-3-Core/core.html#Text3-replaceWholeText
This seems to be an edge case with the nested entity this test wanted to cover.
Why Xerces fails to throw it (TextImpl.java): To validate the replacement,
TextImpl calls canModifyNext(Node). When it encounters a nested entity, it
recursively calls canModifyNext:
1. canModifyNext("Test: ")
2. Iterates to adjacent entity &ent5;
3. Iterates over children of &ent5; and hits nested entity &ent6;
4. Recursively calls canModifyNext(&ent6;)
5. The Bug: canModifyNext(node) immediately calls node.getNextSibling(). As a
result, it skips checking the children of &ent6;, completely missing the <foo/>
element.
See testWholeText in tests/dom/dom3/Test.java
> Replacing entity node should fail
> ---------------------------------
>
> Key: XERCESJ-1801
> URL: https://issues.apache.org/jira/browse/XERCESJ-1801
> Project: Xerces2-J
> Issue Type: Bug
> Components: DOM (Level 3 Core)
> Reporter: Elliotte Rusty Harold
> Priority: Minor
>
> see thread on https://github.com/apache/xerces-j/pull/96/changes#r3914030798
> According to the DOM Level 3 Core specification, replacing this node is
> strictly expected to fail and raise a NO_MODIFICATION_ALLOWED_ERR. Because
> entities=true is set earlier, the logically adjacent EntityReference node
> (&ent5;) is expanded as read-only. We should likely revert this specific
> check to a try-catch asserting the DOMException, otherwise the test loses its
> ability to enforce the W3C spec compliance here. ->
> https://www.w3.org/TR/DOM-Level-3-Core/core.html#Text3-replaceWholeText
> This seems to be an edge case with the nested entity this test wanted to
> cover.
> Why Xerces fails to throw it (TextImpl.java): To validate the replacement,
> TextImpl calls canModifyNext(Node). When it encounters a nested entity, it
> recursively calls canModifyNext:
> 1. canModifyNext("Test: ")
> 2. Iterates to adjacent entity &ent5;
> 3. Iterates over children of &ent5; and hits nested entity &ent6;
> 4. Recursively calls canModifyNext(&ent6;)
> 5. The Bug: canModifyNext(node) immediately calls node.getNextSibling(). As a
> result, it skips checking the children of &ent6;, completely missing the
> <foo/> element.
> See testWholeText in tests/dom/dom3/Test.java
> The behavior the test tests for and that Xerces currenlty implements is
> likely incorrect per spec
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
