| 09:38 | <JakeA> | I'm playing around with the storage access API, and it just seems… totally broken. Am I holding it wrong? https://static-misc-2.glitch.me/storage-in-iframe/ |
| 09:39 | <JakeA> | In Firefox, there appears to be _no change_ after calling `requestStorageAccess`, other than `hasStorageAccess` now returning true |
| 09:40 | <JakeA> | IDB, localstorage, cache storage, service worker, are not double keyed to begin with |
| 09:40 | <JakeA> | Cookie setting via JS appears to be a no-op before and after `requestStorageAccess` |
| 09:44 | <JakeA> | Actually, I'm wrong on the cookie thing. Cookies are not double-keyed/blocked either |
| 09:48 | <annevk> | JakeA: it seems weird that hasStorageAccess returned false before if there was no change, file a bug on that? |
| 09:48 | <annevk> | JakeA: I suspect the general issue is that Firefox only uses this API for domains categorized as trackers |
| 09:48 | <annevk> | JakeA: which makes it harder to test |
| 09:49 | <JakeA> | annevk: Maybe. Safari's behaviour seems nonsensical here too fwiw, but in exciting different ways. Maybe if there was a spec… |
| 09:49 | <annevk> | JakeA: afaik Safari only flips cookies from blocked to non-blocked |
| 09:50 | <annevk> | JakeA: no disagreement there |
| 09:50 | <annevk> | JakeA: I've been trying to figure out a way forward, but it's rather hard given all the constraints everyone has and all the weird hacks that have been piled on to date |
| 09:51 | <JakeA> | annevk: Safari seems weirder than that. If I get storage access, setting cookies still fails, unless I also set the cookie in the top level page, _then_ the iframed page can also set cookies |
| 09:51 | <JakeA> | So weird |
| 09:52 | <annevk> | 😞 |
| 09:52 | <JakeA> | I'll ping Joh about it |
| 09:52 | <JakeA> | um, John* |
| 10:03 | <JakeA> | annevk: filed https://bugzilla.mozilla.org/show_bug.cgi?id=1622212. Dunno if it's in the right component |
| 10:04 | <annevk> | JakeA: thanks, has the right triage owner so that'll be fine |
| 10:06 | <JakeA> | annevk: While you're here, do you know anyone at Mozilla that'd be interested in chatting about <portal>? I'm working on making it requestStorageAccess friendly, and trying to persuade Chrome folks to strongly align it with bfcache. |
| 10:09 | <annevk> | JakeA: https://github.com/mozilla/standards-positions/issues/157 suggests dbaron has thoughts (not necessarily positive) |
| 10:13 | <JakeA> | The "not explained enough" thing is totally fair, and that's what I'm trying to fix. I guess I'd rather this was designed across browsers rather than it being Chrome-only design and other vendors getting a binary choice. |
| 16:36 | <annevk> | Domenic: I'm a bit worried about using "obtaining an agent cluster key" for the cache key as we don't want that to change based on COOP+COEP |
| 16:36 | <annevk> | Domenic: we should probably have a "obtain a site" algorithm that it delegates to |
| 16:39 | <Domenic> | annevk: that makes sense |
| 16:45 | <annevk> | Domenic: shall we turn convert-policy into publish-sg-data or some such? |
| 16:45 | <annevk> | hmm, I guess technically we could write a separate python script for the non-markdown stuff |
| 16:45 | <annevk> | maybe that's nicer |
| 17:01 | <annevk> | shu: another way would be SAB -> ABS |
| 17:02 | <shu> | annevk: like as an alias? |
| 17:02 | <annevk> | I'm not sure how strongly I feel about not making constructor-exposure host controlled though |
| 17:02 | <annevk> | shu: I was thinking rename |
| 17:02 | <shu> | well, i guess that doesn't "break" feature detection code but deteriorates existing sites, i guess |
| 17:03 | <shu> | it's a bigger refactor ask |
| 17:09 | <shu> | annevk: btw how do you feature detect COOP+COEP? |
| 17:09 | <shu> | (in the version where SAB isn't gated) |
| 17:14 | <annevk> | shu: self.crossOriginIsolated |
| 17:14 | <shu> | cool thanks |
| 17:14 | <annevk> | shu: https://annevankesteren.nl/2020/01/shared-memory-feature-detection |
| 17:17 | <shu> | i'm also wondering if it's possible to build use counters in such a way so we can gauge risk of eventually making SAB available everywhere |
| 17:17 | <shu> | i guess it'd be a counter that, on either SAB construction or self.crossOriginIsolated, checks if the other was also used in this page load |
| 17:17 | <shu> | not sure if the infra supports that |
| 17:20 | <shu> | annevk: sure, in the spec we can say constructor exposure host-dependent, though of course it'd be nicer for there to be interop here when we launch COOP+COEP |
| 17:21 | <shu> | technically, i'm not very convinced by luke's future-proofing motivation here. i do like the symmetry though |
| 17:23 | <annevk> | shu: that phrase meant to say that I'm okay with adopting what you were (initially) proposing |
| 17:23 | <shu> | ah, okay |
| 17:23 | <annevk> | host is HTML, it'd still be defined |
| 17:24 | <annevk> | it'd require changes to ECMAScript though which is its own hurdle |
| 17:24 | <shu> | annevk: let's circle back on monday, i'm waiting to chat with the wasm team here about what they want to do about WebAssembly.Memory({shared:true}) |
| 17:24 | <shu> | annevk: what needs to change in ecma262? |
| 17:24 | <annevk> | shu: well it currently exposes the constructor |
| 17:24 | <annevk> | shu: that would need to be gated on some host-provided flag, no? |
| 17:24 | <shu> | the conditional removal, because of a host-defined thing, instead of squinting and saying that the host is able to delete stuff already? |
| 17:25 | <shu> | annevk: i'll bring it up at the upcoming meeting |
| 17:25 | <annevk> | shu: I guess there's a question as to how much is not exposed and if you could still get at a SAB if there were something that returned them |
| 17:26 | <shu> | annevk: right, i'm not approaching it mainly as a compat concern |
| 17:26 | <annevk> | as for Wasm.Memory, I was under the impression that was all SAB under the hood |
| 17:26 | <shu> | annevk: the postMessage check is going to remain |
| 17:26 | <shu> | err, s/not// |
| 17:27 | <shu> | i *am* approaching it mainly as a compat concern |
| 17:27 | <shu> | it is SAB under the hood, but IIUC there's no compat concern about making WebAssembly.Memory({shared:true}) always available |
| 17:28 | <shu> | or maybe there's just no research |
| 17:28 | <shu> | maybe the wasm folks have independent reason to want that to be always available |
| 17:29 | <annevk> | I'm gonna be out for two weeks or so, though probably will be mostly at home so might check in from time to time, Luke will (hopefully) take point |
| 17:30 | <shu> | got it |
| 17:40 | <Domenic> | annevk: shu: I don't think it requires ES changes. We just modify https://html.spec.whatwg.org/#creating-a-new-javascript-realm to delete SharedArrayBuffer from the resulting global object. |
| 17:41 | <annevk> | beautiful |
| 17:42 | <shu> | a note on the allowance is probably warranted from the 262 side |
| 23:10 | <Domenic> | nahhhhh |
| 23:11 | <Domenic> | Seems similar to a note allowing running scripts which use the delete operator. Anything configurable is fair game IMO. |