-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTML: document.open() and aborting documents #10789
Conversation
It appears non-Firefox does not terminate fetches and therefore probably does not run
as required by the HTML Standard. |
}); | ||
client.send(); | ||
frame.contentDocument.open(); | ||
happened = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the purpose of this to fail the test if frame.contentDocument.open()
somehow synchronously aborts the running script? Seems far-fetched, so maybe that's not it...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TimothyGu suggests there's also the case where error events are fired synchronously, which this would catch.
|
||
// Since the "unload a document" algorithm is currently executed before "abort | ||
// a document", the following two tests technically test the "unload" algorithm | ||
// since that is where "make disappear a WebSocket object" is called, rather |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside: "make disappear" is a brilliant name for some steps :)
Based on the work by Anne van Kesteren in whatwg#3651, but without the parts concerning the session history. Changes to that area will come later (see whatwg#3818). Tests: web-platform-tests/wpt#10773 Tests: web-platform-tests/wpt#10778 Tests: web-platform-tests/wpt#10789 Tests: web-platform-tests/wpt#10815 Tests: web-platform-tests/wpt#10818 Fixes whatwg#1698. Fixes whatwg#3286. Fixes whatwg#3306. Closes whatwg#3665. Co-authored-by: Anne van Kesteren <[email protected]>
Updated PR flipped the reference conditions.
See investigation in whatwg#3818. Tests: web-platform-tests/wpt#10789
a6a862c
to
ae9ad45
Compare
This implements the "ideal 2" plan in whatwg#3651, which is found to be compatible with the existing Chrome test suite. Closes whatwg#3651. Fixes whatwg#3975. Tests: web-platform-tests/wpt#10789
6353140
to
b623d1b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few suggestions, but overall good to go. The only thing I'd really like done is moving .src assignments after .onload assignments; the rest is up to your judgment.
html/webappapis/dynamic-markup-insertion/opening-the-input-stream/resources/meta-refresh.py
Show resolved
Hide resolved
async_test(t => { | ||
const frame = document.body.appendChild(document.createElement("iframe")); | ||
t.add_cleanup(() => frame.remove()); | ||
frame.src = "resources/meta-refresh.py?0"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would make me more comfortable if you put the .src assignments after the .onload assignments in all cases. I'm not sure what exactly is allowed per spec, but in the past we've tried to make tests follow that order.
...dynamic-markup-insertion/opening-the-input-stream/abort-refresh-multisecond-header.window.js
Show resolved
Hide resolved
}, "document.open() does not abort documents that are not navigating (image loading)"); | ||
|
||
async_test(t => { | ||
const __SERVER__NAME = "{{host}}"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why __
prefix?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was to use the convention in https://github.com/web-platform-tests/wpt/blob/master/websockets/websocket.sub.js.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could change the websocket variables.
@@ -0,0 +1,5 @@ | |||
import time |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe best to dedupe this with https://github.com/web-platform-tests/wpt/blob/master/html/semantics/scripting-1/the-script-element/resources/slow.py into /common?=
html/webappapis/dynamic-markup-insertion/opening-the-input-stream/resources/http-refresh.py
Outdated
Show resolved
Hide resolved
b1aeb1b
to
fa75e02
Compare
For #10773. Co-authored-by: Anne van Kesteren <[email protected]>
fa75e02
to
0a04996
Compare
This implements the "ideal 2" plan in #3975, which was found to be compatible with the existing Chrome test suite while being reasonably straightforward. Closes #3651. Fixes #3975. Tests: web-platform-tests/wpt#10789
Currently, we have different behaviors for the "having a provisional document loader" state versus the "having a queued navigation" state. In the first case, we call FrameLoader::StopAllLoaders(), which cancels the ongoing navigation as well as fetches on the current page (e.g. XMLHttpRequest). In the second, we merely cancel the task to navigate, but do NOT cancel fetches. Indeed, it is recognized that the spec is currently unclear about canceling queued navigation vs. direct navigation (see [1]). However, it is worth noting that Chrome does not always follow the spec with this distinction in the first place (through location.href, for example, which queues a navigation task in Chrome but navigates directly in spec). Additionally, since even the current code cancels navigation in both circumstances (the only disagreement being if peripheral fetches are also canceled), we see no reason to have an inconsistency in this regard (see [2]). This CL now always calls FrameLoader::StopAllLoaders(), for both when we have a provisional loader and when we have a queued navigation, thus ridding ourselves of the inconsistency. By doing so, we implement the "ideal 2" plan laid out in [2], which recently became part of the HTML Standard in [3]. Tests for this new behavior (which this CL fully passes) are in [4], which was imported into our tree by the WPT Importer bot, whose expectations this CL now change. [1]: whatwg/html#3447 [2]: whatwg/html#3975 [3]: whatwg/html#3999 [4]: web-platform-tests/wpt#10789 Bug: 866274 Change-Id: I4e3ffac6b7c07bc8da812f6f210ab5d6933bdfd1 Reviewed-on: https://chromium-review.googlesource.com/1195837 Commit-Queue: Timothy Gu <[email protected]> Reviewed-by: Nate Chapin <[email protected]> Reviewed-by: Kent Tamura <[email protected]> Cr-Commit-Position: refs/heads/master@{#590011}
This implements the "ideal 2" plan in whatwg#3975, which was found to be compatible with the existing Chrome test suite while being reasonably straightforward. Closes whatwg#3651. Fixes whatwg#3975. Tests: web-platform-tests/wpt#10789
This implements the "ideal 2" plan in whatwg#3975, which was found to be compatible with the existing Chrome test suite while being reasonably straightforward. Closes whatwg#3651. Fixes whatwg#3975. Tests: web-platform-tests/wpt#10789
For #10773.
This PR (now) tests the new spec text proposed in whatwg/html#3818.