Fix GH-16039: Segmentation fault (access null pointer) in ext/dom/parentnode/tree.c

dom_object_get_node() can fail if we don't have a user object
associated.

Closes GH-16056.

Fix crash in ParentNode::append() when dealing with a fragment containing text nodes

Credits for test: https://github.com/PhpGt/Dom/pull/454.

Closes GH-14206.

Fix broken cache invalidation with deallocated and reallocated document node

The original caching implementation had an oversight in combination with
the new lifetime management in DOM f

Fix broken cache invalidation with deallocated and reallocated document node

The original caching implementation had an oversight in combination with
the new lifetime management in DOM for 8.3.
The modification counter is stored on the document object itself, but as
that can get deallocated when all references disappear, stale cache data
can be used. Normally this isn't a problem, unless getElementsByTagName is
called not on the document but on a child node. Fix it by moving caching
data into the ref object, which will outlive all nodes from a document
even if the document object disappears.

Closes GH-12338.

show more ...

Use zend_result as return for properties in ext/dom (#12113)

Optimize checks for DOMParentNode and DOMChildNode

Because we check the list with dom_sanity_check_node_list_for_insertion()
before dom_is_node_in_list(), then we don't have to check the

Optimize checks for DOMParentNode and DOMChildNode

Because we check the list with dom_sanity_check_node_list_for_insertion()
before dom_is_node_in_list(), then we don't have to check the object
type anymore in dom_is_node_in_list(), because
dom_sanity_check_node_list_for_insertion() will have already done that.

Closes GH-11914.

show more ...

Align DOMChildNode parent checks with spec

Closes GH-11905.

Make DOMChildNode::remove() run in O(1) performance

This method had some useless logic in it. It checked whether the child
node is a child of its parent, which is always true of course.

Make DOMChildNode::remove() run in O(1) performance

This method had some useless logic in it. It checked whether the child
node is a child of its parent, which is always true of course.
But I know where this check comes from, if you follow the spec closely
you'll find that the spec used to have explicit child and parent
arguments for the removal algorithm [1].
That's because that algorithm is written in a generic way, where the
parent and child arguments might not come from the same subtree.
However, in this particular case it *is* always the case that the child
is a child of its parent. The checks weren't needed back then for
DOMChildNode::remove(), and are still not needed today.

[1] e.g. https://web.archive.org/web/20180601092634/https://dom.spec.whatwg.org/#concept-node-remove

show more ...

Implement DOMParentNode::replaceChildren()

ref: https://dom.spec.whatwg.org/#dom-parentnode-replacechildren

Add missing cache invalidation in dom_child_replace_with()

This was forgotten during an earlier merge.

[ci skip] Fix inaccurate comment

Use uint32_t for the number of nodes (#11371)

Implement iteration cache, item cache and length cache for node list iteration (#11330)

* Implement iteration cache, item cache and length cache for node list iteration

The current

Implement iteration cache, item cache and length cache for node list iteration (#11330)

* Implement iteration cache, item cache and length cache for node list iteration

The current implementation follows the spec requirement that the list
must be "live". This means that changes in the document must be
reflected in the existing node lists without requiring the user to
refetch the node list.
The consequence is that getting any item, or the length of the list,
always starts searching from the root element of the node list. This
results in O(n) time to get any item or the length. If there's a for
loop over the node list, this means the iterations will take O(n²) time
in total. This causes real-world performance issues with potential for
downtime (see GH-11308 and its references for details).

We fix this by introducing a caching strategy. We cache the last
iterated object in the iterator, the last requested item in the node
list, and the last length computation. To invalidate the cache, we
simply count the number of modifications made to the containing
document. If the modification number does not match what the number was
during caching, we know the document has been modified and the cache is
invalid. If this ever overflows, we saturate the modification number and
don't do any caching anymore. Note that we don't check for overflow on
64-bit systems because it would take hundreds of years to overflow.

Fixes GH-11308.

show more ...

Remove unnecessary tree setting in dom_zvals_to_fragment()

This is already done by xmlNewDocText().

Closes GH-11345.

Fix GH-8329 Print true/false instead of bool in error and debug messages (#8385)

Fix segfault when DOMParentNode::prepend() is called when the child disappears

Closes GH-11906.

Fix viable next sibling search for replaceWith

Closes GH-11888.

Fix viable next sibling search for replaceWith

Closes GH-11888.

Fix GH-11830: ParentNode methods should perform their checks upfront

Closes GH-11887.

Handle fragments consisting out of multiple children without a single root correctly

Closes GH-11698.

Fix GH-11625: DOMElement::replaceWith() doesn't replace node with DOMDocumentFragment but just deletes node or causes wrapping <></> depending on libxml2 version

Depending on the libxml2 ver

Fix GH-11625: DOMElement::replaceWith() doesn't replace node with DOMDocumentFragment but just deletes node or causes wrapping <></> depending on libxml2 version

Depending on the libxml2 version, the behaviour is either to not
render the fragment correctly, or to wrap it inside <></>. Fix it by
unpacking fragments manually. This has the side effect that we need to
move the unlinking check in the replacement function to earlier because
the empty child list is now possible in non-error cases.
Also fixes a mistake in the linked list management.

Closes GH-11627.

show more ...

Fix bug #81642: DOMChildNode::replaceWith() bug when replacing a node with itself

Closes GH-11363.

Fix bug #67440: append_node of a DOMDocumentFragment does not reconcile namespaces

The test was amended from the original issue report. For the test:
Co-authored-by: php@deep-freeze.ca

Fix bug #67440: append_node of a DOMDocumentFragment does not reconcile namespaces

The test was amended from the original issue report. For the test:
Co-authored-by: php@deep-freeze.ca

The problem is that the regular dom_reconcile_ns() only works on a
single node. We actually have to reconciliate the whole tree in case a
fragment was added. This also required to move some code around such
that this special case could be handled separately.

Closes GH-11362.

show more ...

Fix DOMElement::append() and DOMElement::prepend() hierarchy checks

We could end up in an invalid hierarchy, resulting in infinite loops and
eventual crashes if we don't check for the DO

Fix DOMElement::append() and DOMElement::prepend() hierarchy checks

We could end up in an invalid hierarchy, resulting in infinite loops and
eventual crashes if we don't check for the DOM hierarchy validity.

Closes GH-11344.

show more ...

Fix GH-11288 and GH-11289 and GH-11290 and GH-9142: DOMExceptions and segfaults with replaceWith

This replaces the implementation of before and after with one following
the spec very str

Fix GH-11288 and GH-11289 and GH-11290 and GH-9142: DOMExceptions and segfaults with replaceWith

This replaces the implementation of before and after with one following
the spec very strictly, instead of trying to figure out the state we're
in by looking at the pointers. Also relaxes the condition on text node
copying to prevent working on a stale node pointer.

Closes GH-11299.

show more ...

Fix incorrect error handling in dom_zvals_to_fragment()

Discovered this pre-existing problem while testing GH-10682.
Note: this problem existed *before* that PR.

* Not all paths

Fix incorrect error handling in dom_zvals_to_fragment()

Discovered this pre-existing problem while testing GH-10682.
Note: this problem existed *before* that PR.

* Not all paths throw a hierarchy request error
* xmlFreeNode must be used instead of xmlFree for the fragment to also
free its children.
* Free up nodes that couldn't be added when xmlAddChild fails.

I unified the error handling code that's exactly the same with a goto to
prevent at least some of such problems in the future.

Closes GH-10981.

show more ...