document.close() sets document.readyState synchronously |
|
Issue descriptionChrome Version: (copy from chrome://version) 70.0.3535.0 (Official Build) canary (64-bit) OS: (e.g. Win10, MacOS 10.12, etc...) macOS 10.13.6 What steps will reproduce the problem? document.open(); document.close(); console.log(document.readyState); What is the expected result? "interactive" is printed. This is the case in Firefox (but not Safari). Per spec, the readiness is changed to "complete" in a queued task (https://html.spec.whatwg.org/multipage/parsing.html#stop-parsing step 7). What happens instead? "complete" is printed.
,
Sep 30
timothygu@, is there a test in WPT that shows the difference in behavior here? Would it be the final parts of https://github.com/web-platform-tests/wpt/pull/10844, if landed?
,
Oct 4
foolip@, the linked PR is indeed a test for this topic, but the code fragment
frame.onload = t.step_func_done(() => {
[...]
frame.contentDocument.close();
assert_equals(frame.contentDocument.readyState, "complete");
assert_array_equals(states, ["interactive", "complete"]);
});
would need to be changed to
frame.onload = t.step_func(() => {
[...]
frame.contentDocument.close();
assert_equals(frame.contentDocument.readyState, "interactive");
assert_array_equals(states, ["interactive"]);
frame.contentDocument.onreadystatechange = t.step_func_done(() => {
assert_equals(frame.contentDocument.readyState, "complete");
});
});
to reflect the current specification. The PR as it stands uses the current Chrome behavior as reference.
|
|
►
Sign in to add a comment |
|
Comment 1 by donghee....@gmail.com
, Aug 29