* PHP-8.2:
Fix crash when calling childNodes next() when iterator is exhausted
Fix references not handled correctly in C14N
Fix crashes when entity declaration is removed while still having entity references
PHP 8.1 introduced a seemingly unintentional BC break in ca94d55a19 by
blocking the (un)serialization of DOM objects.
This was done because the serialization never really worked and just
resulted in an empty object, which upon unserialization just resulted in
an object that you can't use.
Users can however implement their own serialization methods, but the
commit made that impossible as the ACC flag gets passed down to the
child class. An approach was tried in #10307 with a new ACC flag to
selectively allow serialization with subclasses if they implement the
right methods. However, that was found to be too ad hoc.
Instead, let's abuse how the __sleep and __wakeup methods work to throw
the exception instead. If the child class implements the __serialize /
__unserialize method, then the throwing methods won't be called.
Similarly, if the child class implements __sleep and __wakeup, then
they're overridden and it doesn't matter that they throw.
For the user, this PR has the exact same behaviour for (sub)classes that
don't implement the serialization methods: an exception will be thrown.
For code that previously implemented subclasses with these methods, this
approach will make that code work again. This approach should be both BC
preserving and unbreak user's code.
Closes GH-12388.
For the test:
Co-authored-by: wazelin <contact@sergeimikhailov.com>
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.
For typed properties that are of type "string", we don't need to do any
conversion as the zval will already be a string. Removing this
simplifies code and avoids unnecessary refcounting.
* PHP-8.2:
Fix GH-11455: Segmentation fault with custom object date properties
Revert "Fix GH-11404: DOMDocument::savexml and friends ommit xmlns="" declaration for null namespace, creating incorrect xml representation of the DOM"
* PHP-8.1:
Revert "Fix GH-11404: DOMDocument::savexml and friends ommit xmlns="" declaration for null namespace, creating incorrect xml representation of the DOM"
This reverts commit 7eb3e9cd17.
Although the fix follows the spec, it causes issues because a lot of old
code assumes the incorrect behaviour PHP had since a long time.
We cannot do this yet, especially not in a stable release.
We revert this for the time being.
See GH-11428.
* PHP-8.2:
Fix GH-11404: DOMDocument::savexml and friends ommit xmlns="" declaration for null namespace, creating incorrect xml representation of the DOM
* PHP-8.1:
Fix GH-11404: DOMDocument::savexml and friends ommit xmlns="" declaration for null namespace, creating incorrect xml representation of the DOM
The NULL namespace is only correct when there is no default namespace
override. When there is, we need to manually set it to the empty string
namespace.
Closes GH-11428.
The length is passed to xmlStrndup(), which also adds 1, and adds a null
terminator past the end. It worked because the length is not actually
stored. Strings in libxml2 are null terminated. Passing the length just
avoids a call to strlen().
A few callers remove all children of a node. The way it was done in
node.c was unsafe, because it left nodep->last dangling. It just happens
to not crash if xmlNodeSetContent() is called immediately afterwards.
* PHP-8.2:
Fix bug #77686: Removed elements are still returned by getElementById
Fix bug #81642: DOMChildNode::replaceWith() bug when replacing a node with itself
Fix bug #67440: append_node of a DOMDocumentFragment does not reconcile namespaces
* PHP-8.1:
Fix bug #77686: Removed elements are still returned by getElementById
Fix bug #81642: DOMChildNode::replaceWith() bug when replacing a node with itself
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.
* 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.
We can't directly call xmlNodeSetContent, because it might encode the string
through xmlStringLenGetNodeList for types
XML_DOCUMENT_FRAG_NODE, XML_ELEMENT_NODE, XML_ATTRIBUTE_NODE.
In these cases we need to use a text node to avoid the encoding.
For the other cases, we *can* rely on xmlNodeSetContent because it is either
a no-op, or handles the content without encoding and clears the properties
field if needed.
The test was taken from the issue report, for the test:
Co-authored-by: ThomasWeinert <thomas@weinert.info>
Closes GH-10245.
