| 06:37 | <hsivonen> | Domenic: What's the story behind https://wpt.fyi/results/html?label=master&label=experimental&aligned&view=subtest&q=window-reuse-in-nested-browsing-contexts.tentative.html ? I'm trying to make Gecko's initial about:blank more Web-compatible, and I now have a patch that results in Chrome-consistent behavior on that test: 6 fails and 1 pass (the single pass being "iframe with initial src == same-origin resource."). Despite what I have said earlier (when I believed it was worthwhile to pursue Presto-style initial about:blank), I now have strong doubts about the usefulness of pursuing the expectations of this test. |
| 06:38 | <Domenic> | Hmm! |
| 06:39 | <Domenic> | Where is that open issue.... |
| 06:40 | <Domenic> | https://github.com/whatwg/html/issues/546 and https://github.com/whatwg/html/issues/3267 I think |
| 06:42 | <hsivonen> | https://github.com/whatwg/html/issues/546 and https://github.com/whatwg/html/issues/3267 I think |
| 06:42 | <Domenic> | My position is pretty generic: we should do anything that we can get interop on and is web-compatible; ideally that thing should be somewhat principled. |
| 06:43 | <Domenic> | In the past I've been reluctant to change the spec away from Gecko behavior because Gecko put a lot of work into this and their approach seemed principled. But if you're up for it, let's do so. |
| 06:43 | <Domenic> | Now I need to figure out how to spec it. It'll be on top of https://github.com/whatwg/html/pull/6315 although I don't think the Window reuse parts changed much. |
| 06:44 | <hsivonen> | I have a hard time seeing Gecko's currently-released about:blank behavior as principled. |
| 06:45 | <Domenic> | Would you be kind enough to drop a comment in one of those issues explaining exactly what WebKit/Blink-style about:blank is and how you might spec it? I see the test results matrix but it'd take me some time to reload this all into my brain enough to understand the right approach. |
| 06:47 | <Domenic> | Also, it sounds like you might be supportive of my upcoming pitch to add navigation/history to Interop 2023 :) |
| 07:06 | <hsivonen> | Would you be kind enough to drop a comment in one of those issues explaining exactly what WebKit/Blink-style about:blank is and how you might spec it? I see the test results matrix but it'd take me some time to reload this all into my brain enough to understand the right approach. |
| 07:21 | <Domenic> | Perfect, thank you! I will add that into https://github.com/whatwg/html/pull/6315 so we can close the two issues. I will also happily approve any WPT changes in that direction. You might want to adopt the tests from the abandoned https://chromium-review.googlesource.com/c/chromium/src/+/804797 to make sure the full matrix from that issue is covered... |
| 07:21 | <Domenic> | I guess I should say that on the issue to record our plan of record |
| 13:25 | <zcorpan> |
|
| 14:44 | <Dominic Farolino> | Is there a guarantee that aborting a fetch will result in the promise being rejecting? Wondering if it's possible to abort a fetch after the resolve microtask is already queued, in which case I'd expect the fetch promise to resolve (since the abort came in too late). Is that how it works? |
| 14:49 | <annevk> | Dominic Farolino: yeah, since abort also queues so that would happen after (it doesn't reach into the queue and modify things) |
| 14:51 | <Chris de Almeida> | https://dom.spec.whatwg.org/#abortcontroller-api-integration |
| 14:58 | <Dominic Farolino> | annevk: Thanks! Btw do you have any opinions on: when abort() is called, whether the promise-returning API should immediately reject while it kicks off its cancelation steps, vs rejecting after we wait on some cancelation steps to "finish up"? |
| 14:58 | <Dominic Farolino> | I'm seeing this done in a mixed way, but didn't know if there was a clearly recommended path. |
| 15:07 | <annevk> | Dominic Farolino: the link Chris de Almeida posted above addresses how we expect integration to work. Which boil down to cancelation happening first (though possibly later if that's async) and then rejecting the promise. |
| 15:07 | <annevk> | Oh my, that example doesn't queue a task to resolve despite it clearly happening in parallel. |
| 15:11 | <Chris de Almeida> | what do you mean? isn't that in step 3 ? |
| 15:14 | <Dominic Farolino> | Chris de Almeida: I think promise resolution has to happen on a task on the "main" thread |
| 15:14 | <Dominic Farolino> | So the timing would be (1) Queue a task to resolve the promise, (2) One microtask later, the promise gets resolved |
| 15:15 | <annevk> | step 3.2 needs to queue a task |
| 15:16 | <Chris de Almeida> | annevk: I believe that's covered by saying "in parallel" where parallel links to the queue details |
| 15:17 | <Dominic Farolino> | annevk: Regarding that spec integration link, the example shows that we first "Stop doing [...]", and then we reject the promise. But if "Stop doing [...]" kicks off a ton of async work in another process, my question is: should we block the rejection on all that work completing? |
| 15:17 | <Dominic Farolino> | That example indicates the answer is no, but it isn't in the normative requirements so I'm not totally sure |
| 15:19 | <annevk> | Chris de Almeida: it's not |
| 15:20 | <annevk> | Dominic Farolino: pretty sure "no", but worth filing an issue to stipulate that more clearly (as well as to fix the queuing) |
| 15:21 | <Chris de Almeida> | https://github.com/whatwg/dom/issues/1031 |
| 15:22 | <Chris de Almeida> | see last comment in particular.. I see you've already seen this issue 🙂 |
| 15:24 | <Dominic Farolino> | I have not seen this issue |
| 15:24 | <Dominic Farolino> | Different Dom(i|e)nic |
| 15:24 | <Chris de Almeida> | I meant annevk |
| 15:24 | <Dominic Farolino> | Ah haha. Thanks for finding it though! Looks like Domenic's opinion is that we should block rejection on the cancelation steps "going through" |
| 16:09 | <annevk> | Thanks for finding that Chris de Almeida . I personally think that we should reject early and then do our best to abort the actual operation. That's what fetch() does as well. |
| 16:12 | <Dominic Farolino> | annevk: You mentioned that for e.g., fetch(), the promise could still resolve after abort() is called since "abort also queues". But I can't see where it queues, can you point it out to me? |
| 16:24 | <smaug> | Hmm, does anyone have data about Origin-Agent-Cluster usage? |
| 16:57 | <annevk> | Dominic Farolino: it indeed doesn't queue, I think it would happen synchronously and thus become observable at the next microtask checkpoint |
| 17:04 | <Dominic Farolino> | OK, in that case I think it is impossible for a fetch() promise to ever resolve after the fetch is abort()ed |
| 17:06 | <annevk> | Dominic Farolino: yeah, unless the abort() somehow runs in the task that resolves; I think that shouldn't be possible, at least not until we add some kind of FetchObserver with events |
| 17:07 | <annevk> | Domenic might... |
| 23:47 | <Domenic> | smaug: looks like about 0.3% of page views: https://chromestatus.com/metrics/feature/timeline/popularity/3286 |
| 23:47 | <Domenic> | (I tried to rename the use counter when we renamed the header but it seems to have not worked.) |
| 23:48 | <Domenic> | It's a bit of a weird header because of https://github.com/whatwg/html/pull/7617 flipping its primary use case |
| 23:48 | <Domenic> | Although even after that, explicit Origin-Agent-Cluster: ?1 still might be treated as a process allocation hint, different than omitting it. (That is Chromium's current plan.) |