WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(4.38 KB, patch)
2021-07-09 17:07 PDT
,
Chris Dumez
ews-feeder
: commit-queue-
Details
Formatted Diff
Diff
Patch
(6.84 KB, patch)
2021-07-09 20:11 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
Patch
(7.20 KB, patch)
2021-07-10 13:59 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Chris Dumez
Comment 1
2021-07-09 16:15:57 PDT
Created
attachment 433246
[details]
Patch
Chris Dumez
Comment 2
2021-07-09 17:07:02 PDT
Created
attachment 433248
[details]
Patch
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
Created
attachment 433254
[details]
Patch
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
<
rdar://problem/80408826
>
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
Created
attachment 433272
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug