Replies: 2 comments 2 replies
-
|
All tickets related to the current milestone 0.9.0 have been closed. If nothing else comes up the current version will be released as 0.9.0 in the near future. |
Beta Was this translation helpful? Give feedback.
-
|
I suggest adding instructions for upgrading from "0.8". The constructor options of
P. S. I'm not confident that no further changes are needed in my code to push the "0.9.9" upgrade to production. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
All Commits
0.9.9
Added
ParentNode.childrengetter#960/#410Fixed
createCDATASectionnow throwsInvalidCharacterErrorwhendatacontains"]]>", as required by the WHATWG DOM spec.GHSA-wh4c-j3r5-mjhpXMLSerializernow splits CDATASection nodes whose data contains"]]>"into adjacent CDATA sections at serialization time, preventing XML injection via mutation methods (appendData,replaceData,.data =,.textContent =).GHSA-wh4c-j3r5-mjhpNode.contains#931Code that passes a string containing
"]]>"tocreateCDATASectionand relied on the previously unsafe behavior will now receiveInvalidCharacterError. Use a mutation method such asappendDataif you intentionally need"]]>"in a CDATASection node's data.Chore
Thank you,
@stevenobiajulu,
@yoshi389111,
@thesmartshadow,
for your contributions
0.9.8
Fixed
#839/#838#847/#838Chore
#845Thank you,
@kboshold,
@Ponynjaa,
for your contributions.
0.9.7
Added
hasAttributes#804Fixed
#802/#803#817/#819Performance
DOM.compareDocumentPosition#805Chore
Thank you,
@zorkow,
@Ponynjaa,
@WesselKroos,
for your contributions.
0.9.6
Fixed
#790/#794/#797Chore
#792Thank you, @eglitise, for your contributions.
0.9.5
Fixed
#763/#766Thank you,
@mureinik,
for your contributions.
0.9.4
Fixed
#748/#760warning(fix(types): correct error handler level towarning#759)#754/#759Docs
#758Thank you, @luffynando, @mattiasw, @JoinerDev, for your contributions.
0.9.3
Fixed
NodeandProcessingInstructiontypes#725/#726getElements*methods returnLiveNodeList<Element>#731/#734Nodeprops#728, triggered by unclosed#724Docs
Chore
Thank you, @Ponynjaa, @ayZagen, @sserdyuk, @wydengyre, @mykola-mokhnach, @benkroeger, for your contributions.
0.9.2
Feature
Element.getElementsByClassName#722Fixed
Document.documentElementandElement.tagName#721#720Thank you, @censujiang, @Mathias-S, for your contributions
0.9.1
Fixed
#713isHTMLMimeTypein type definition#715/#712#717/#285/#695Other
#710Thank you, @krystofwoldrich, @marvinruder, @amacneil, @defunctzombie, @tjhorner, @danon, for your contributions.
0.9.0
Summary on dev.to
Features
#637/#40#634/#633Fixed
#692#554#550Other
#556#697#546#524#566#644#511Thank you, @kboshold, @edi9999, @apupier, @shunkica, @homer0, @jhauga, @UdayKharatmol, for your contributions
0.9.0-beta.11
Fixed
#519/#45/#125/#467BREAKING-CHANGE: Reports more not well-formed documents as fatalError
and drop broken support for optional and unclosed tags in HTML.
Other
#518#517Thank you, @brodybits, @cbettinger, @josecarlosrx, for your contributions
0.9.0-beta.10
Fixed
#514/#499Chore
#513Thank you, @qtow, @shunkica, @homer0, for your contributions
0.9.0-beta.9
Fixed
#509/#505#498/#497/#117BREAKING CHANGES: Many documents that were previously accepted by xmldom, esecially non well-formed ones are no longer accepted. Some issues that were formerly reported as errors are now a fatalError.
#454Chore
#496toErrorSnapshotwindows compatible#503Thank you, @cjbarth, @shunkica, @pmahend1, @niklasl, for your contributions
0.9.0-beta.8
Fixed
#494/#135BREAKING CHANGE: Previously it was possible (but not documented) to call
Node.removeChildwith any node in the tree,and with certain exceptions, it would work. This is no longer the case: calling
Node.removeChildwith an argument that is not a direct child of the node that it is called from, will throw a NotFoundError DOMException, as it is described by the specs.Thank you, @noseworthy, @davidmc24, for your contributions
0.9.0-beta.7
Feature
compareDocumentPositionmethod from level 3 spec.#488Fixed
getAttributeandgetAttributeNSshould returnnull(fix:getAttributeandgetAttributeNSshould returnnull#477)#46#46#485/#486#489BREAKING CHANGE: Iteration over attributes now happens in the right order and non-existing attributes now return
nullinstead of undefined. THe same is true for thenamepsaceURIandprefixof Attr nodes.All of the changes are fixing misalignment with the DOM specs, so if you expected it to work as specified,
nothing should break for you.
Chore
#481/#483Thank you, @bulandent, @zorkow, for your contributions
0.9.0-beta.6
Fixed
#457/#455/#456Thank you, @edemaine, @pedro-l9, for your contributions
0.9.0-beta.5
Fixed
#452/#453Thank you, @fengxinming, for your contributions
0.9.0-beta.4
Fixed
CVE-2022-39353In case such a DOM would be created, the part that is not well-formed will be transformed into text nodes, in which xml specific characters like
<and>are encoded accordingly.In the upcoming version 0.9.0 those text nodes will no longer be added and an error will be thrown instead.
This change can break your code, if you relied on this behavior, e.g. multiple root elements in the past. We consider it more important to align with the specs that we want to be aligned with, considering the potential security issues that might derive from people not being aware of the difference in behavior.
Related Spec: https://dom.spec.whatwg.org/#concept-node-ensure-pre-insertion-validity
Chore
lib#448/#190#447/#29/#130Thank you, @XhmikosR, @awwright, @frumioj, @cjbarth, @markgollnick for your contributions
0.9.0-beta.3
Fixed
#445/#416BREAKING CHANGE: It no longer reports an error when parsing HTML containing incomplete closing tags, to align the behavior with the one in the browser.
BREAKING CHANGE: If your code relied on not well-formed XML to be parsed and include subsequent tags, this will no longer work.
#440Other
#444Thank you, @ACN-kck, @mgerlach for your contributions
0.9.0-beta.2
Fixed
#437/#436Thank you, @Supraja9726 for your contributions
0.9.0-beta.1
Fixed
Only use HTML rules if mimeType matches
#338, fixes#203In the living specs for parsing XML and HTML, that this library is trying to implement,
there is a distinction between the different types of documents being parsed:
There are quite some rules that are different for parsing, constructing and serializing XML vs HTML documents.
So far xmldom was always "detecting" whether "the HTML rules should be applied" by looking at the current namespace. So from the first time an the HTML default namespace (
http://www.w3.org/1999/xhtml) was found, every node was treated as being part of an HTML document. This misconception is the root cause for quite some reported bugs.BREAKING CHANGE: HTML rules are no longer applied just because of the namespace, but require the
mimeTypeargument passed toDOMParser.parseFromString(source, mimeType)to match'text/html'. Doing so implies all rules for handling casing for tag and attribute names when parsing, creation of nodes and searching nodes.BREAKING CHANGE: Correct the return type of
DOMParser.parseFromStringtoDocument | undefined. In case of parsing errors it was always possible that "the returnedDocument" has not been created. In case you are using Typescript you now need to handle those cases.BREAKING CHANGE: The instance property
DOMParser.optionsis no longer available, instead use the individualreadonlyproperty per option (assign,domHandler,errorHandler,normalizeLineEndings,locator,xmlns). Those also provides the default value if the option was not passed. The 'locator' option is now just a boolean (default remainstrue).BREAKING CHANGE: The following methods no longer allow a (non spec compliant) boolean argument to toggle "HTML rules":
XMLSerializer.serializeToStringNode.toStringDocument.toStringThe following interfaces have been implemented:
DOMImplementationnow implements all methods defined in the DOM spec, but not all of the behavior is implemented (see docstring):createDocumentcreates an "XML Document" (prototype:Document, propertytypeis'xml')createHTMLDocumentcreates an "HTML Document" (type/prototype:Document, propertytypeis'html').falseno child nodes are createdDocumentnow has two new readonly properties as specified in the DOM spec:contentTypewhich is the mime-type that was used to create the documenttypewhich is either the string literal'xml'or'html'MIME_TYPE(/lib/conventions.js):hasDefaultHTMLNamespacetest if the provided string is one of the miem types that implies the default HTML namespace:text/htmlorapplication/xhtml+xmlThank you @weiwu-zhang for your contributions
Chore
0.9.10
Commits
Fixed
XMLSerializer.serializeToString()(andNode.toString(),NodeList.toString()) now accept arequireWellFormedoption. When{ requireWellFormed: true }is passed, the serializer throwsInvalidStateErrorfor injection-prone node content, preventing XML injection via attacker-controlled node data.GHSA-j759-j44w-7fr8GHSA-x6wf-f3px-wcqxGHSA-f6ww-3ggp-fr8hdatacontains--anywhere, ends with-, or contains characters outside the XMLCharproduction:or matchesxml(case-insensitive), ordatacontains characters outside the XMLCharproduction or contains?>publicIdfailsPubidLiteral,systemIdfailsSystemLiteral, orinternalSubsetcontains]>XMLSerializer.serializeToString(),Node.prototype.normalize(),Node.prototype.cloneNode(true),Document.prototype.importNode(node, true),node.textContentgetter,getElementsByTagName()/getElementsByTagNameNS()/getElementsByClassName()/getElementById(),Node.prototype.isEqualNode()) are now iterative. Previously, deeply nested DOM trees would exhaust the JavaScript call stack and throw an unrecoverableRangeError.GHSA-2v35-w6hq-6mfwisEqualNodenow correctly returnsfalsefor CDATASection nodes with differentdataDeprecated
splitCDATASectionsserializer option is deprecated and will be removed in the next breaking release. The automatic splitting of"]]>"inCDATASectiondata was introduced as a workaround; userequireWellFormed: trueor ensureCDATASectiondata does not contain"]]>"before serialization.Chore
Thank you,
@Jvr2022,
@praveen-kv,
@TharVid,
@decsecre583,
@tlsbollei,
@KarimTantawey,
for your contributions
Beta Was this translation helpful? Give feedback.
All reactions