Skip to content

Commit a330317

Browse files
cdumezcdumez
committed
document.readyState should be "complete" after calling DOMParser.parseFromString()
https://bugs.webkit.org/show_bug.cgi?id=227846 Reviewed by Ryosuke Niwa. LayoutTests/imported/w3c: Rebaseline WPT test that is now passing. * web-platform-tests/domparsing/xmldomparser-expected.txt: Source/WebCore: document.readyState should be "complete" after calling DOMParser.parseFromString(). This is causing the following WPT test to fail in WebKit: http://wpt.live/domparsing/xmldomparser.html Both Gecko and Blink report the correct readyState here. No new tests, rebaselined existing test. * dom/Document.cpp: (WebCore::Document::explicitClose): explicitClose() normally calls checkCompleted() which calls FrameLoader::checkCompleted(), which ends up setting the document's ready state to "complete" and then calling Document::implicitClose(). However, when the document has no frame (which is the case for a document just created via DOMParser.parseFromString()), we would call Document::implicitClose() directly, since we don't have a FrameLoader. As a result, the document's ready state would stay "interactive". To address the issue, we now set the document's ready state to "complete" before calling implicitClose(), similarly to what FrameLoader::checkCompleted() would have done. Canonical link: https://commits.webkit.org/239575@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@279814 268f45cc-cd09-0410-ab3c-d52691b4dbfc
1 parent aaff132 commit a330317

File tree

7 files changed

+85
-3
lines changed

7 files changed

+85
-3
lines changed

‎LayoutTests/fast/dom/Document/createdDocument-readyState-expected.txt

+19
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
Tests document.readyState() for documents created by JavaScript
2+
3+
On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
4+
5+
6+
htmlDocument = document.implementation.createHTMLDocument()
7+
PASS htmlDocument.readyState is "loading"
8+
htmlDocument.close()
9+
PASS htmlDocument.readyState is "complete"
10+
xhtmlDocument = document.implementation.createDocument('http://www.w3.org/1999/xhtml', 'html', null)
11+
PASS xhtmlDocument.readyState is "complete"
12+
svgDocument = document.implementation.createDocument('http://www.w3.org/2000/svg', 'svg', null)
13+
PASS svgDocument.readyState is "complete"
14+
xmlDocument = (new DOMParser()).parseFromString('', 'text/xml')
15+
PASS xmlDocument.readyState is "complete"
16+
PASS successfullyParsed is true
17+
18+
TEST COMPLETE
19+

‎LayoutTests/fast/dom/Document/createdDocument-readyState.html

+22
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
<!DOCTYPE html>
2+
<html>
3+
<body>
4+
<script src="../../../resources/js-test.js"></script>
5+
<script>
6+
description("Tests document.readyState() for documents created by JavaScript");
7+
8+
evalAndLog("htmlDocument = document.implementation.createHTMLDocument()");
9+
shouldBeEqualToString("htmlDocument.readyState", "loading"); // WebKit and Blink say "loading", Gecko says "complete".
10+
evalAndLog("htmlDocument.close()");
11+
shouldBeEqualToString("htmlDocument.readyState", "complete");
12+
13+
evalAndLog("xhtmlDocument = document.implementation.createDocument('http://www.w3.org/1999/xhtml', 'html', null)");
14+
shouldBeEqualToString("xhtmlDocument.readyState", "complete");
15+
16+
evalAndLog("svgDocument = document.implementation.createDocument('http://www.w3.org/2000/svg', 'svg', null)");
17+
shouldBeEqualToString("svgDocument.readyState", "complete");
18+
19+
evalAndLog("xmlDocument = (new DOMParser()).parseFromString('<html></html>', 'text/xml')");
20+
shouldBeEqualToString("xmlDocument.readyState", "complete");
21+
</script>
22+
</html>

‎LayoutTests/imported/w3c/ChangeLog

+11
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,14 @@
1+
2021-07-10 Chris Dumez <[email protected]>
2+
3+
document.readyState should be "complete" after calling DOMParser.parseFromString()
4+
https://bugs.webkit.org/show_bug.cgi?id=227846
5+
6+
Reviewed by Ryosuke Niwa.
7+
8+
Rebaseline WPT test that is now passing.
9+
10+
* web-platform-tests/domparsing/xmldomparser-expected.txt:
11+
112
2021-07-10 Commit Queue <[email protected]>
213

314
Unreviewed, reverting r279803.

‎LayoutTests/imported/w3c/web-platform-tests/domparsing/xmldomparser-expected.txt

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,3 @@
11

2-
FAIL XML Dom Parse readyState Test assert_equals: expected "complete" but got "interactive"
2+
PASS XML Dom Parse readyState Test
33

‎LayoutTests/imported/w3c/web-platform-tests/xhr/responsexml-document-properties-expected.txt

+1-1
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ PASS baseURI
66
PASS referrer
77
PASS title
88
PASS contentType
9-
FAIL readyState assert_equals: expected "complete" but got "interactive"
9+
PASS readyState
1010
PASS location
1111
PASS defaultView
1212
PASS body

‎Source/WebCore/ChangeLog

+27
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,30 @@
1+
2021-07-10 Chris Dumez <[email protected]>
2+
3+
document.readyState should be "complete" after calling DOMParser.parseFromString()
4+
https://bugs.webkit.org/show_bug.cgi?id=227846
5+
6+
Reviewed by Ryosuke Niwa.
7+
8+
document.readyState should be "complete" after calling DOMParser.parseFromString().
9+
10+
This is causing the following WPT test to fail in WebKit:
11+
http://wpt.live/domparsing/xmldomparser.html
12+
13+
Both Gecko and Blink report the correct readyState here.
14+
15+
No new tests, rebaselined existing test.
16+
17+
* dom/Document.cpp:
18+
(WebCore::Document::explicitClose):
19+
explicitClose() normally calls checkCompleted() which calls FrameLoader::checkCompleted(),
20+
which ends up setting the document's ready state to "complete" and then calling
21+
Document::implicitClose(). However, when the document has no frame (which is the case
22+
for a document just created via DOMParser.parseFromString()), we would call
23+
Document::implicitClose() directly, since we don't have a FrameLoader. As a result,
24+
the document's ready state would stay "interactive". To address the issue, we now set
25+
the document's ready state to "complete" before calling implicitClose(), similarly to
26+
what FrameLoader::checkCompleted() would have done.
27+
128
2021-07-10 Commit Queue <[email protected]>
229

330
Unreviewed, reverting r279803.

‎Source/WebCore/dom/Document.cpp

+4-1
Original file line numberDiff line numberDiff line change
@@ -1395,7 +1395,9 @@ void Document::setReadyState(ReadyState readyState)
13951395
}
13961396

13971397
m_readyState = readyState;
1398-
dispatchEvent(Event::create(eventNames().readystatechangeEvent, Event::CanBubble::No, Event::IsCancelable::No));
1398+
1399+
if (m_frame)
1400+
dispatchEvent(Event::create(eventNames().readystatechangeEvent, Event::CanBubble::No, Event::IsCancelable::No));
13991401

14001402
if (settings().suppressesIncrementalRendering())
14011403
setVisualUpdatesAllowed(readyState);
@@ -3103,6 +3105,7 @@ void Document::explicitClose()
31033105
// Because we have no frame, we don't know if all loading has completed,
31043106
// so we just call implicitClose() immediately. FIXME: This might fire
31053107
// the load event prematurely <http://bugs.webkit.org/show_bug.cgi?id=14568>.
3108+
setReadyState(Complete);
31063109
implicitClose();
31073110
return;
31083111
}

0 commit comments

Comments
 (0)