DOMParser.parseFromString TypeError: undefined is not an object (evaluating 'new window.HTMLDocument')
Opened this issue · 1 comments
Describe the bug
Using bun, I get the following error when trying to use DOMParser.parseFromString
:
84 | */
85 | #createDocument(mimeType) {
86 | const window = this[PropertySymbol.window];
87 | switch (mimeType) {
88 | case 'text/html':
89 | return new window.HTMLDocument();
^
TypeError: undefined is not an object (evaluating 'new window.HTMLDocument')
at #createDocument (/node_modules/happy-dom/lib/dom-parser/DOMParser.js:89:28)
at parseFromString (/node_modules/happy-dom/lib/dom-parser/DOMParser.js:22:34)
Bun v1.1.30 (macOS arm64)
To Reproduce
Steps to reproduce the behavior:
Run a script with bun that does something like:
import { DOMParser } from "happy-dom";
const parser = new DOMParser();
const page = parser.parseFromString(
`
<!DOCTYPE html>
<html>
<body>
<div>hi</div>
</body>
</html>
`,
"text/html",
);
Expected behavior
A successfully parsed document
Screenshots
Device:
- OS: macOS
- Browser n/a
- Version latest
Additional context
Add any other context about the problem here.
I found another bug related to this feature (lmk if I should report as a different issue) - it seems like this string <body><x></x>Example Text
will not detect body as the root, although it should - this will break HappyDOM for use in frameworks like Angular.
(new window.DOMParser()).parseFromString("<body><x></x>Example Text", "text/html").body.innerHTML
Chrome: <x></x>Example Text
HappyDOM: <body><x></x>Example Text</body>
.
Looks like the cause is in:
tagName
BODY should match as well in order to correctly detect documentTypeNode.It somewhat seems like it's the intent of the next check to catch this case, but I am not sure why that is not working or if the intent is different.
node[PropertySymbol.nodeType] === NodeTypeEnum.documentTypeNode
@capricorn86