| 09:30 | <Ms2ger> | akaster: I make no claims that the current wasm spec is optimal or agrees with browsers in all edge cases on this point :) |
| 17:45 | <Sam Sneddon [:gsnedders]> | https://infra.spec.whatwg.org/#algorithm-limits would arguably cover this; I'd hope this isn't a problem with major browsers given you can with modern APIs on Windows not be concerned about that. |
| 18:52 | <akaster> | Domenic: When implementing HostPromiseRejectionTracker, https://html.spec.whatwg.org/multipage/webappapis.html#the-hostpromiserejectiontracker-implementation, are we expecting that the promise object is the actual JS Promise object? or should it be converted to a WebIDL Promise<T> before doing anything with it in the algorithm per the conversion steps in https://webidl.spec.whatwg.org/#js-promise ? I'm not sure if it is observable whether we e.g. fire a PromiseRejectionEvent with "a PromiseCapability resolved with promise" vs the JS Promise object itself |
| 19:23 | <akaster> | hm. rephrased this question in https://github.com/whatwg/html/issues/10721 |
| 21:17 | <akaster> | heh. let e = new PromiseRejectionEvent('eventName', { promise: 42 }); only throws in Firefox. seems everyone else allows synthetic PromiseRejectionEvents to have a promise property of any type |
| 21:22 | <annevk> | WebKit has required Promise<any> promise; there, which seems kinda what you'd expect? |
| 21:24 | <annevk> | I wonder if this got changed post implementation. It does seem a little wonky that the promise getter can return a non-promise. |
| 21:54 | <akaster> | 🤷I'm adding logic to our IDL generator to convert any Promise<T> properties of IDL interfaces into PromiseCapabiltiies before sending them along to our web engine |
| 21:55 | <akaster> | so in that case, doing so for PromiseRejectionEvent is likely incorrect (pending that issue I posted). So it seems like copying firefox and pretending that it's supposed to be required object promise is easiest to keep moving fwd with the change |
| 22:10 | <annevk> | I would do whatever is easiest as it's just synthetic events that are impacted here and they're a rather niche use case. |
| 22:11 | <annevk> | Though we should also figure out what this should do longer term. :-) Maybe object is reasonable though, just seems odd. |