RESOLVED FIXED 227846
document.readyState should be "complete" after calling DOMParser.parseFromString()
https://bugs.webkit.org/show_bug.cgi?id=227846
Summary document.readyState should be "complete" after calling DOMParser.parseFromStr...
Chris Dumez
Reported 2021-07-09 16:12:05 PDT
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.
Attachments
Patch (3.69 KB, patch)
2021-07-09 16:15 PDT, Chris Dumez
no flags
Patch (4.38 KB, patch)
2021-07-09 17:07 PDT, Chris Dumez
ews-feeder: commit-queue-
Patch (6.84 KB, patch)
2021-07-09 20:11 PDT, Chris Dumez
no flags
Patch (7.20 KB, patch)
2021-07-10 13:59 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2021-07-09 16:15:57 PDT
Chris Dumez
Comment 2 2021-07-09 17:07:02 PDT
Ryosuke Niwa
Comment 3 2021-07-09 17:17:12 PDT
Comment on attachment 433248 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=433248&action=review > Source/WebCore/dom/Document.cpp:3106 > + setReadyState(Complete); Does this also impact document.close?
Sam Weinig
Comment 4 2021-07-09 17:18:44 PDT
Comment on attachment 433248 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=433248&action=review > Source/WebCore/ChangeLog:26 > + * 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. Seems good. I wish we had a better model of dealing with frameless documents, so we aren't duplicating functionality.
Chris Dumez
Comment 5 2021-07-09 17:31:41 PDT
(In reply to Ryosuke Niwa from comment #3) > Comment on attachment 433248 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=433248&action=review > > > Source/WebCore/dom/Document.cpp:3106 > > + setReadyState(Complete); > > Does this also impact document.close? Not super familiar with `document.close()` but looking at the code, it seems to only have an impact on documents created by JS because of this early return: ``` if (!scriptableDocumentParser() || !scriptableDocumentParser()->wasCreatedByScript() || !scriptableDocumentParser()->isParsing()) return; ``` Documents created by scripts should now have a readyState that is "complete" after my patch so calling close() on the document later on should not make a difference on the readyState since it is already "complete". Am I missing something?
Ryosuke Niwa
Comment 6 2021-07-09 17:38:44 PDT
(In reply to Chris Dumez from comment #5) > (In reply to Ryosuke Niwa from comment #3) > > Comment on attachment 433248 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=433248&action=review > > > > > Source/WebCore/dom/Document.cpp:3106 > > > + setReadyState(Complete); > > > > Does this also impact document.close? > > Not super familiar with `document.close()` but looking at the code, it seems > to only have an impact on documents created by JS because of this early > return: > ``` > if (!scriptableDocumentParser() || > !scriptableDocumentParser()->wasCreatedByScript() || > !scriptableDocumentParser()->isParsing()) > return; > ``` > > Documents created by scripts should now have a readyState that is "complete" > after my patch so calling close() on the document later on should not make a > difference on the readyState since it is already "complete". Am I missing > something? How about document.implementation.createDocument/createHTMLDocument?
Chris Dumez
Comment 7 2021-07-09 20:00:11 PDT
(In reply to Ryosuke Niwa from comment #6) > (In reply to Chris Dumez from comment #5) > > (In reply to Ryosuke Niwa from comment #3) > > > Comment on attachment 433248 [details] > > > Patch > > > > > > View in context: > > > https://bugs.webkit.org/attachment.cgi?id=433248&action=review > > > > > > > Source/WebCore/dom/Document.cpp:3106 > > > > + setReadyState(Complete); > > > > > > Does this also impact document.close? > > > > Not super familiar with `document.close()` but looking at the code, it seems > > to only have an impact on documents created by JS because of this early > > return: > > ``` > > if (!scriptableDocumentParser() || > > !scriptableDocumentParser()->wasCreatedByScript() || > > !scriptableDocumentParser()->isParsing()) > > return; > > ``` > > > > Documents created by scripts should now have a readyState that is "complete" > > after my patch so calling close() on the document later on should not make a > > difference on the readyState since it is already "complete". Am I missing > > something? > > How about document.implementation.createDocument/createHTMLDocument? I think I'll add some test and make sure our behavior is consistent with other engines.
Chris Dumez
Comment 8 2021-07-09 20:11:42 PDT
EWS
Comment 9 2021-07-09 22:21:45 PDT
Committed r279803 (239567@main): <https://commits.webkit.org/239567@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 433254 [details].
Radar WebKit Bug Importer
Comment 10 2021-07-09 22:22:17 PDT
WebKit Commit Bot
Comment 11 2021-07-10 13:06:37 PDT
Re-opened since this is blocked by bug 227850
Chris Dumez
Comment 12 2021-07-10 13:59:12 PDT
EWS
Comment 13 2021-07-10 21:16:12 PDT
Committed r279814 (239575@main): <https://commits.webkit.org/239575@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 433272 [details].
Note You need to log in before you can comment on or make changes to this bug.