00:05
<Domenic>
javascript: URL navigation is just a normal navigation I believe. It's a new Window, and a new Document.
08:59
<keithamus>
annevk: WPTs for revamped scoped custom elements test Element customElementRegistry - but the spec IDL has Element customElements - which one is the most up to date? Was this the compat issue?
09:00
<keithamus>
nvm, looks like I answered my own question looking at https://github.com/web-platform-tests/wpt/commit/1b4c64d41f2b8f41b7b6215900eaf63e2e8a9f94
09:56
<annevk>
jmdyck: thanks, that's fixed now.
09:57
<annevk>
LI Daobing: file an issue against whatwg/html on GitHub. Also linked from the top of https://html.spec.whatwg.org/multipage/
09:58
<annevk>
keithamus: which specification PR still has customElements? I thought I had updated all of that quite a while back.
09:59
<keithamus>
I think it's actually just the comment: https://github.com/whatwg/html/issues/10854#issue-2735341285
10:00
<annevk>
Oh, well please don't implement based on that.
10:00
<keithamus>
I was just stubbing out the necessary APIs based on it
10:01
<annevk>
Oh no. Well, I'll update it, but please don't do that again. We really need implementers to implement based from the specification drafts.
14:20
<Maxim Vaarwel>

What example satisfies it? I tried many ways and none of them worked.

The rules for choosing a navigable

  1. If currentDocument's opener policy's value is "same-origin" or "same-origin-plus-COEP", and currentDocument's origin is not same origin with currentDocument's relevant settings object's top-level origin, then:
    1. Set noopener to true.
    2. Set name to "_blank".
    3. Set windowType to "new with no opener".
      ...
  2. Return chosen and windowType.

window open steps

  1. Let targetNavigable and windowType be the result of applying the rules for choosing a navigable given target, sourceDocument's node navigable, and noopener.
  2. If noopener is true or windowType is "new with no opener", then return null.
15:51
<Shima Ryuhei>

Hey, I have a question about this part of the Streams spec.

In the spec, there's this assertion during return():
https://streams.spec.whatwg.org/#rs-asynciterator

Assert: reader.[[readRequests]] is empty, as the async iterator machinery guarantees that any previous calls to next() have settled before this is called.

But it seems like this assumption can be broken if you call return() directly before the previous next() settles.

Here’s a minimal example:

let controller;
const stream = new ReadableStream({
  start(c) {
    controller = c;
  }
});

const iter = stream[Symbol.asyncIterator]();
let next1Promise = iter.next();
let next2Promise = iter.next();

controller.enqueue("Hello");

await next1Promise;

iter.return();  

This was originally raised in Node.js here:
https://github.com/nodejs/node/issues/57679

In this section of the Web IDL spec, should the return method call the asynchronous iterator return steps only after the previous next call has settled?

Or am I missing something?

16:10
<zcorpan>
Hmmm. The test uses the initial about:blank document and then sets src, which is a case where Window is not replaced ( https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13663 ). But even when navigating from a document that is not the initial about:blank, I get window reuse when navigating to a javascript: URL, see https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13662
16:13
<zcorpan>
The first case is https://html.spec.whatwg.org/#initialise-the-document-object:~:text=If%20browsingContext%27s%20active%20document%27s%20is%20initial%20about%3Ablank%20is%20true%2C%20and%20browsingContext%27s%20active%20document%27s%20origin%20is%20same%20origin%2Ddomain%20with%20navigationParams%27s%20origin%2C%20then%20set%20window%20to%20browsingContext%27s%20active%20window%2E
16:15
<zcorpan>
The javascript: case is https://html.spec.whatwg.org/#the-javascript:-url-special-case which creates a Document (if a string is returned) but I'm not sure now if it says to reuse the window
16:49
<zcorpan>
Wait, === will compare the WindowProxy, right? How do I tell if the Window was replaced?
17:41
<zcorpan>
https://chromium-review.googlesource.com/c/chromium/src/+/804797/5/third_party/WebKit/LayoutTests/external/wpt/html/browsers/the-window-object/reuse-across-navigation/same-origin.html uses an expando, which makes sense, but I couldn't get that to work in live dom viewer. Maybe the issue is testing in live dom viewer
18:29
<Maxim Vaarwel>
annevk Dominic Farolino could you help me?