Editorial: adopt Fetch's new approach to callbacks #311
Conversation
There was a problem hiding this comment.
This looks reasonable, but the dance of having processResponse set a boolean and then waiting for the boolean seems like it'd be painful if it was repeated for every in-parallel fetch in the HTML spec. (Especially since those cases won't deal with timeout.) I'd kind of prefer having Fetch do that for us still...
| @@ -851,7 +836,8 @@ return <a>this</a>'s <a>cross-origin credentials</a>. | |||
| </ol> | |||
| <!-- upload complete flag can never be set here I hope --> | |||
|
|
|||
| <p>To <a>process response</a> for <var>response</var>, run these steps: | |||
| <li> | |||
| <p>Let <var>processResponse</var>, given a <var>response</var>, be these steps: | |||
There was a problem hiding this comment.
Some steps use "terminate these steps" to bail, others use "return". Probably "abort these steps" is most common and best?
There was a problem hiding this comment.
So I would kinda prefer if we could use return everywhere as it's a lot more convenient. And some of these algorithms can be invoked from in parallel and main thread alike.
There was a problem hiding this comment.
It's not a matter of parallel or main thread. It's a matter of which algorithm they terminate. "Return" as we use it today terminates the main algorithm...
Maybe it's unambiguous to allow it to terminate the innermost algorithm, but it seems a bit tricky.
There was a problem hiding this comment.
The thing I don't understand is why a step in a callback or a step in in parallel steps could ever terminate the main algorithm. It seems you would always have to handle that with some kind of flag.
There was a problem hiding this comment.
Well, some callbacks are called synchronously (e.g. readable stream read request steps), and so could theoretically return. But I agree it's an unlikely reading.
It's more that, when I go to scan an algorithm, I want to look for all "return"/"throw" lines and say "that's where the algorithm could terminate". If we allow re-using return to break out of a collection of steps, then I have to mentally discard those in my scan.
I don't have a strong argument for why this is more problematic for me in specs than it is in programming languages. Maybe the lack of syntax highlighting, or the fact that substeps for callbacks look very similar to substeps for if statements. But I hope this help explains my mild preference.
|
I don't think we need that setup in HTML, do we? What in HTML needs to block the main thread? In HTML we'd just put all subsequent steps in the callback. (Assuming HTML is doing it correctly in parallel now, which I somewhat doubt.) |
Nobody but XMLHttpRequest take a dependency on this please. You have been warned. Context: whatwg/xhr#311.
|
Thanks for all the great review feedback by the way! |
Nobody but XMLHttpRequest take a dependency on this please. You have been warned. Context: whatwg/xhr#311.
|
Hmm, yeah, after Ctrl+Fing all instances of "Fetch request" in HTML, they all seem like they'd work fine. I thought we had more instances where we did fetches from in-parallel, but I guess not. (The only real one is during navigation which we just discussed in IRC.) |
See whatwg/fetch#1165 for context.
* Editorial: remove redundant "the" * Meta: default branch rename Also correct a broken link. Not even w3.org URLs are that cool. Helps with whatwg/meta#174. * Editorial: clean up calls to "parse a URL" It actually takes a string, so calls should be clear about that. * Review Draft Publication: January 2021 * Simplify <link>s In particular, remove their activation behavior, stop them from matching :link and :visited, and stop suggesting that they be focusable areas. This also includes a slight expansion and rearrangement of the link element's section to make it clearer what hyperlinks created by <link> are meant for, contrasting them to <a> and <area> hyperlinks. Closes whatwg#4831. Closes whatwg#2617. Helps with whatwg#5490. * Meta: remove demos/offline/* (whatwg#6307) These are no longer needed as of e4330d5. * Meta: minor references cleanup Use more HTTPS and drop obsolete HTML Differences reference. * Editorial: anticlockwise → counterclockwise We use en-US these days. Spotted in https://twitter.com/iso2022jp/status/1352601086519955456. * Use :focus-visible in the UA stylesheet See w3c/csswg-drafts#4278. * Editorial: align with WebIDL and Infra * Fix "update a style block" early return The new version matches implementation reality and CSSWG resolution. The algorithm was also inconsistent, as it looked at whether the element was in a shadow tree or in the document tree, but it was only specified to be re-run if the element becomes connected or disconnected. The CSSWG discussed this in w3c/csswg-drafts#3096 (comment) and http://wpt.live/shadow-dom/ShadowRoot-interface.html tests this. This also matches closer the definition of <link rel="stylesheet">, which does use connectedness (though it uses "browsing-context connected", which is a bit different): https://html.spec.whatwg.org/#link-type-stylesheet * Modernize and refactor simple dialogs This contains a small bug fix, in that confirm() and prompt() said "return" in some cases instead of "return false" or "return null" as appropriate. Other notable changes, all editorial, are: * Factoring out repeated "cannot show simple dialogs" steps, which will likely expand over time (see e.g. whatwg#6297). * Separating out and explaining the no-argument overload of alert(). * Passing the document through to the "printing steps", instead of just having them talk about "this Window object". * Meta: add definition markup for MessageEvent * Remove <marquee> events They are only supported by one engine (Gecko). Closes whatwg#2957. * Clarify when microtasks happen * Ignore COEP on non-secure contexts Fixes whatwg#6328. * Editorial: update URL Standard integration * Editorial: only invoke response's location URL once Complements whatwg/fetch#1149. * Track the incumbent settings and active script in Promise callbacks Closes whatwg#5213. * createImageBitmap(): stop clipping sourceRect to source's dimensions It has been found in whatwg#6306 that this was an oversight at the time of its introduction. Current behavior goes against author expectations and no implementer has opposed the change to "no-clip". Tests: web-platform-tests/wpt#27040. Closes whatwg#6306. * Remove CSP plugin-types blocking With Flash not being supported anymore, the CSP directive plugin-types has lost its main reason for being and is being removed from the Content Security Policy specification: w3c/webappsec-csp#456. This change removes references to the relevant algorithm from the Content Security Policy spec. * Meta: set more dfn types A follow-up to: * whatwg#5694 * whatwg#5916 * Editorial: occuring → occurring * Make all plugin-related APIs no-ops Part of whatwg#6003. * Disallow simple dialogs from different-origin domain iframes Closes whatwg#5407. * Revive @@iterator for PluginArray/MimeTypeArray/Plugin @@iterator is implicitly installed by defining an indexed property getter. Since there is no other way to define it exclusively, this restores some methods back to being indexed getters. This fixes an inadvertent observable behavior change in d4f07b8. * Adjust web+ scheme security considerations to account for FTP removal Also, network scheme is now reduced to HTTP(S) scheme. Helps with whatwg#5375, but form submission issue remains. See whatwg/fetch#1166 for context. * Meta: export pause Nobody but XMLHttpRequest take a dependency on this please. You have been warned. Context: whatwg/xhr#311. * Fix typo: ancestor → accessor Fixes whatwg#6374. Co-authored-by: Dominic Farolino <domfarolino@gmail.com> Co-authored-by: Anne van Kesteren <annevk@annevk.nl> Co-authored-by: Domenic Denicola <d@domenic.me> Co-authored-by: Emilio Cobos Álvarez <emilio@crisal.io> Co-authored-by: Momdo Nakamura <xmomdo@gmail.com> Co-authored-by: Jake Archibald <jaffathecake@gmail.com> Co-authored-by: Yutaka Hirano <yhirano@chromium.org> Co-authored-by: Shu-yu Guo <syg@chromium.org> Co-authored-by: Kaiido <tristan.fraipont@gmail.com> Co-authored-by: Antonio Sartori <anton.sartori@gmail.com> Co-authored-by: Michael[tm] Smith <mike@w3.org> Co-authored-by: Ikko Ashimine <eltociear@gmail.com> Co-authored-by: Carlos IL <carlosjoan91@gmail.com> Co-authored-by: Kagami Sascha Rosylight <saschanaz@outlook.com> Co-authored-by: Simon Pieters <zcorpan@gmail.com>
See whatwg/fetch#1165 for context.
@domenic so it seems XHR does all the awkward ways of reading a response body without helper. Lots of technical debt came with the introduction of streams to fetch. I didn't try to touch that here and instead focused purely on adopting the new callback approach, which does seem a lot cleaner in terms of what things get to run concurrently and such, but that does seem like an obvious thing to try to tackle next.
Preview | Diff