| 04:06 | <Kris Kowal> | @shu We do a thing in SES that Mark calls “enablements” to compensate for the override mistake which may be of interest: We replace the non-writable property with a getter/setter pair. The prototype is still effectively frozen, but assignment-override works. We’d be delighted to be in touch. |
| 16:47 | <Michael Ficarra> | Kris Kowal: Yes, we considered taking this approach for Iterator.prototype[Symbol.toStringTag] because of this exact issue with regenerator-runtime (see https://github.com/tc39/proposal-iterator-helpers/pull/213), but instead decided to just make the property writable |
| 16:51 | <ljharb> | this is interesting: https://twitter.com/webreflection/status/1697518069554299121 - isn't there some security thing around SAB that this seems to bypass via wasm? |
| 16:54 | <shu> | that's always been the case (since COOP/COEP shipped) |
| 16:54 | <shu> | it's explicitly allowed, and wpt uses it in testing |
| 16:54 | <shu> | the actual capability is the sharing of memory, not the SAB constructor. without COI you still can't postMessage the buffer across workers |
| 16:54 | <bakkot> | the problem isn't getting a SAB, it's being able to share it to workers |
| 16:55 | <bakkot> | see step 13.1.1 of https://html.spec.whatwg.org/#structuredserializeinternal |
| 16:55 | <shu> | this is my "fault" technically: https://github.com/whatwg/html/issues/4732#issuecomment-598470434 |
| 16:56 | <shu> | but we did it for compat reasons for chrome users |
| 16:56 | <Kris Kowal> | Kris Kowal: Yes, we considered taking this approach for |
| 16:59 | <shu> | the original plan, was, in fact, to make SAB always available |
| 17:15 | <ljharb> | ah ok, thanks, that makes sense |
| 17:50 | <leobalter> | Stage 3 won't become a silver bullet for proposal changes. |
| 18:44 | <Michael Ficarra> | of course, changes can be made in response to implementation feedback |
| 18:45 | <Michael Ficarra> | the point of this change is to catch necessary changes before we get to the point of implementation so we don't waste implementers' time, not to have an indicator of rock-solid stability |
| 21:28 | <littledan> | Huh, facilitating feature detection seems like a good thing… |
| 21:28 | <littledan> | (I saw parts of this controversy but never really followed along closely enough) |
| 21:30 | <littledan> | I agree with Leo. Actually, HTML integration is already a Stage 3 requirement in practice, just randomly enforced by certain delegates (including me), and it has been this way for years |
| 21:30 | <littledan> | We should document this |
| 21:30 | <littledan> | It feels funny to have html be special but it just is |
| 21:30 | <littledan> | I think that is why we have hesitated to document it so far |
| 21:33 | <Michael Ficarra> | littledan: I agree but I don't think it needs to be combined with my proposed process change |
| 21:34 | <Michael Ficarra> | as we saw at the last meeting, it is already hard for some delegates to understand the process change |
| 21:34 | <littledan> | littledan: I agree but I don't think it needs to be combined with my proposed process change |
| 21:34 | <littledan> | As far as I am concerned, HTML integration is already a requirement, just a poorly documented one, unlike your proposal which is a genuine change in how we work |
| 21:49 | <shu> | process or no process my personal resolve going forward is i will block stage 3 on proposals where there's non-trivial amounts of semantics in the integration, and the integration is not yet done |
| 23:03 | <shu> | eh, i guess arguably the right way to feature detect is self.crossOriginIsolated, not the existence of the SAB constructor |
| 23:51 | <Michael Ficarra> |
😩 |