WHATWG
2023-02-13
plaintext logs
prev next
source on github
09:37
<Ms2ger>
Use the a element, that's what it's for
09:55
<networkException>

Hey, I'm having trouble implementing some steps relating to the WebIDL Promise type:

In react to a Promise

  1. Let constructor be promise.[[Promise]].[[Realm]].[[Intrinsics]].[[%Promise%]].

I would assume the promise given to be a PromiseCapability Record as the [[Promise]] field (containing "an object that is usable as a promise") gets accessed.

However, in the case of fetching the descendants of and linking a module script

  1. Let loadingPromise be record.LoadRequestedModules(state).
  1. Upon fulfillment of loadingPromise, run the following steps:

loadingPromise (which is passed to fulfillment and react subsequently) is clearly (already?) a promise object and and not a capability record, returned by LoadRequestedModules:

  1. Let pc be ! NewPromiseCapability(%Promise%).
  1. Return pc.[[Promise]].
10:03
<Ms2ger>
Looks like a bug in LoadRequestedModules
10:15
<networkException>
so the WebIDL promise is supposed to be a capability record then? It would be good to have that clarified
10:27
<Ms2ger>

IDL promise type values are represented by ECMAScript PromiseCapability records.

10:27
<Ms2ger>
https://webidl.spec.whatwg.org/#es-promise
10:28
<Andreu Botella>
wait, does that mean that an operation of the form Promise<any> identity(Promise<any> input) cannot return the input promise object?
10:29
<Andreu Botella>
and that any operation that takes a Promise<T> can't resolve or reject the promise
10:29
<Andreu Botella>
though I guess only the wasm streaming API takes a promise
10:30
<networkException>
https://webidl.spec.whatwg.org/#es-promise
ah great, I'm blind :)
10:58
<Ms2ger>
wait, does that mean that an operation of the form Promise<any> identity(Promise<any> input) cannot return the input promise object?
Well, no, because it's a capability both ways
11:10
<annevk>
Andreu Botella: there's waitUntil() in service workers
11:12
<Andreu Botella>
oh, right
11:13
<Andreu Botella>
I guess it is a potential spec-writing pitfall if spec authors don't realize using the resolve/reject algorithms on promises converted from JS objects won't work
11:14
<Andreu Botella>
but it seems like only those two cases take promises, so it's fine for now
11:26
<annevk>
Andreu Botella: you're thinking of a pattern whereby a promise is supplied that the spec will resolve? Can't immediately think of a use case for that
11:26
<Andreu Botella>
I don't have a use case, it's just something I intuitively expected to be able to do
11:33
<annevk>
The only output parameter use case we have thus far is for byte buffers, which makes sense. I do agree though that as far as IDL goes there's a lot of potential cleanup to be done there around JS and IDL objects and how specifications can manage that.
11:40
<sideshowbarker>

annevk: Does the WebKit team have any position on WebHID stated anywhere other than it just being in the “Here are some examples of features we have decided to not yet implement due to fingerprinting, security, and other concerns” list at https://webkit.org/tracking-prevention/#anti-fingerprinting?

I looked in the standards-position issue tracker but didn’t find anything.

11:44
<annevk>
sideshowbarker: I'm not sure if there's a stated position. There would have to be something either on standards-positions or webkit-dev for that.
11:45
<sideshowbarker>
OK
13:21
<Ms2ger>
annevk: what is "this's relevant Realm" in a static method? https://fetch.spec.whatwg.org/#dom-response-error
13:25
<annevk>
Ms2ger: hmm, spec-UB?
13:27
<Ms2ger>
Yeah, seems like "this" is null in https://webidl.spec.whatwg.org/#dfn-create-operation-function
13:27
<Andreu Botella>
more like a spec bug – it seems clear that this should be the realm in which the Response interface object was constructed, right?
13:29
<annevk>
Andreu Botella: spec-UB is a bug :-) And I don't think we have access to that realm. Prolly needs to use current.
13:30
<Andreu Botella>
I think current might give the wrong result sometimes (Response.error() instanceof Response being false)
13:31
<Andreu Botella>
oh, wait, that's not right turns out it is right
13:32
<annevk>
I feel like we should charge all this tech debt to the person who came up with sync script access frames
13:34
<Ms2ger>
Filed https://github.com/whatwg/fetch/issues/1603
13:37
<Pierre-Yves Gérardy>
In https://html.spec.whatwg.org/multipage/nav-history-apis.html#named-access-on-the-window-object the names object is mentioned in step 3, but only defined in step 4. I understand that it is a permanent object that may pre-exist when the algo runs but it isn't mentioned... Is it a spec bug?
13:38
<Andreu Botella>
Andreu Botella: spec-UB is a bug :-) And I don't think we have access to that realm. Prolly needs to use current.
Response.[[Realm]] should be that realm, IIUC
13:47
<Ms2ger>
In https://html.spec.whatwg.org/multipage/nav-history-apis.html#named-access-on-the-window-object the names object is mentioned in step 3, but only defined in step 4. I understand that it is a permanent object that may pre-exist when the algo runs but it isn't mentioned... Is it a spec bug?
Looks like a bug
13:48
<Pierre-Yves Gérardy>
Should I file an issue?
13:49
<Ms2ger>
Yes please
13:49
<Ms2ger>
cc Domenic
13:55
<Pierre-Yves Gérardy>
https://github.com/whatwg/html/issues/8881
13:57
<annevk>
Andreu Botella: but how is that different from the current realm?
13:57
<annevk>
Andreu Botella: because where do I get Response from
14:00
<annevk>
Minor milestone: all IDNA feedback has been submitted. All but the CheckBidi feedback (submitted just now) has also been acknowledged. And now we wait for ~2-3 months.
14:15
<Andreu Botella>
Andreu Botella: because where do I get Response from
Oh, right. I don't yet fully understand the differences between current/entry/incumbent... but I think some of the pieces have finally clicked in my head 😅
14:19
<Ms2ger>
Gecko will get the relevant global of the Response.error function, as far as I can tell
14:21
<Jake Archibald>
fwiw, the static methods on Promise do use this
14:21
<Jake Archibald>
I don't know if that's unusual in JS land
14:25
<annevk>
Hmm yeah, this is always so confusing to me
14:25
<Jake Archibald>
I guess the question is, class Foo extends Response {}, what type should Foo.error() be?
14:30
<Jake Archibald>
fwiw, Object.fromEntries() appears to be bound to Object, like Response.error()
14:30
<Jake Archibald>
So maybe promises are the odd one out
14:33
<Jake Archibald>
annevk: our devtools folks are looking into standardising/improving sourcemaps. Is there someone in particular at WebKit who works on that?
14:37
<annevk>
DevTools folks presumably. Perhaps bring it up on some coordination list, depending on what you're looking for?
14:41
<Jake Archibald>
annevk: they're exploring defining sourcemaps (in WHATWG if it makes sense), and they're looking for a WebKit contact, to see if there'd be an objection to such a spec, or any WebKit-specific requirements
16:00
<annevk>
Jake Archibald: if there's a proposal of sorts WebKit/standards-positions would be great
16:00
<annevk>
Jake Archibald: if not I guess email me and I'll ask around
16:01
<Jake Archibald>
annevk: standards-positions sounds fine to me
16:02
<annevk>
(WHATWG makes sense to me, we already have a tooling-related spec)
16:03
<Jake Archibald>
Yeah, especially since sourcemaps aren't specific to JavaScript, so it's not like TC39 is a better fit
16:09
<annevk>
(I vaguely recall yulia also being involved in sourcemap discussions)
16:12
<yulia>
annevk: they're exploring defining sourcemaps (in WHATWG if it makes sense), and they're looking for a WebKit contact, to see if there'd be an objection to such a spec, or any WebKit-specific requirements
I think there are a couple of homes for it. In the past, we've tried to define a more mature home for it, which ended up being the wasm debugging group (originally it was wasm/js debugging group) in w3c but i believe that has folded. fitzgen has the most context regarding the original plans for this
16:14
<yulia>
I would need to spend some time to recall properly how this went last time, happy to help how i can though
16:15
<yulia>
I don' think TC39 is the right place
16:21
<Jake Archibald>
yulia: I'll let them know. I'll get them to file a standards position at Mozilla too
16:25
<yulia>
I personally support getting this moved into a proper spec if we keep working on it, and i think thats going to be the case for now
19:53
<TabAtkins>
WebIDL question: since dictionaries can be argument or return types, their values are limited to things valid for return types - primitives, interfaces, etc. But this means that if you're using a dictionary for an argument type (an options bag, for example), you can't have any of the members be an argument-only type like sequence or record. Right?
19:54
<TabAtkins>
And if correct, uhh, is there any way to get around this so you can specify an options argument that takes a sequence or record for one of the options?
19:54
<TabAtkins>
(The end-run of record<DOMString, Any> is of course possible but desirable to avoid at all costs.)
20:02
<TabAtkins>
wait nm i was misreading the spec, ignore all of the above