| 24 Jan 2022 |
 Andreu Botella (he/they) | I don't know about whether BackgroundFetch adds further requirements, but regular fetch only supports a few schemes: https://fetch.spec.whatwg.org/#scheme-fetch | 10:18:57 |
 annevk | Luca Casonato: I assume https://github.com/whatwg/spec-factory/pull/35#issuecomment-1019990419 looks okay? | 11:20:55 |
 sideshowbarker | In reply to @andreubotella:mozilla.org
I don't know about whether BackgroundFetch adds further requirements, but regular fetch only supports a few schemes: https://fetch.spec.whatwg.org/#scheme-fetch True but regular fetch at least does support http schemes | 11:26:37 |
| sideshowbarker | …but that because only the https: scheme is allowed, or http: for loopback IPs message seems to make clear that BackgroundFetch is even disallowing http — so it’s enforcing some requirement beyond regular fetch | 11:28:04 |
| sideshowbarker | the problem is that the Background Fetch spec itself doesn’t seem to state any such requirement | 11:28:48 |
| sideshowbarker | I guess it’s possible that Chrome is imposing some additional requirement beyond what’s in the spec | 11:29:27 |
| annevk | sideshowbarker: did you try data: URLs? If that doesn't work it is, but otherwise it would follow from Mixed Content | 11:49:34 |
| sideshowbarker | haven’t tried that yet but will | 11:50:01 |
| sideshowbarker | but now I wonder, does Mixed Content say anything about fetches for unknown URL schemes from secure contexts? | 11:53:44 |
| sideshowbarker | I mean, I don’t expect it says anything about the chrome-extension scheme specifically, but maybe something more general | 11:54:25 |
| sideshowbarker | I guess I should just look myself and see | 11:54:39 |
| sideshowbarker | hmm I guess it comes down to chrome-extension not being explicitly defined as “potentially trustworthy” https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-origin | 11:56:58 |
|  frankfromthebeach changed their display name from aliciamay0614 to frankfromthebeach. | 13:07:01 |
| annevk | sideshowbarker: well Fetch only allows https://fetch.spec.whatwg.org/#fetch-scheme | 13:31:03 |
| sideshowbarker | yeah but if that’s the restriction the browser were enforcing in this case, it seems like the browser would be logging an error message which says that, rather than the different one it is actually logging in this case | 13:33:02 |
| sideshowbarker | * yeah but if that’s the restriction the browser were enforcing in this case, it seems like the browser would be logging an error message which says that, rather than the different error message it is actually logging in this case | 13:33:22 |
 Luca Casonato | In reply to @annevk:mozilla.org
Luca Casonato: I assume https://github.com/whatwg/spec-factory/pull/35#issuecomment-1019990419 looks okay? LGTM! | 13:34:23 |
| Luca Casonato | Thanks for getting this landed :-) | 13:34:43 |
| annevk | Ms2ger 💉💉: maybe file a bug against Deno/Node.js for Exposed=* changes too? https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests | 14:26:47 |
 Ms2ger 💉💉 | Oh, that's new, is it? Will do | 14:27:07 |
| Andreu Botella (he/they) | For Deno, link to https://github.com/denoland/deno/issues/13239, since it's gonna take a while to sort that out | 14:27:46 |
| annevk | Thanks! (And yeah, today-ish new.) | 14:28:52 |
| Andreu Botella (he/they) | (cue Ms2ger 💉💉 insisting on me switching to the compilers team at Igalia 🤣) | 14:28:52 |
| Ms2ger 💉💉 | :) | 14:29:00 |
|  @weeb69:matrix.org left the room. | 15:53:22 |
|  arai joined the room. | 17:22:04 |
 mgaudet | 👋 Trying to reason a bit about the expectation around globals and WebIDL interfaces.
I've been looking at some of the JS engine tests we wrote for or streams. One of which tries to assert that if you invoke another global's ReadableStream.prototype.getReader with a stream in your current realm, you get a reader back that is in the other global, not your current one (tested using instanceof)
Right now, Safari and Chrome disagree: Safari has the reader in a different global, Chrome has it in the current global. Firefox disagrees with itself depending on which streams implementation I test: JS-implemented streams agrees with Safari, DOM+WebIDL implemented streams agrees with Chrome.
| 17:24:14 |
| mgaudet | So, in this exact case, the question is one of: Which realm is implied by Step 1 of AcquireReadableStreamDefaultReader, "let reader be a new ReadableStreamDefaultReader" ? new links to the WebIDL spec which asks a specification to specify a realm... | 17:25:57 |
|  evilpie joined the room. | 17:28:14 |
|  Schalk Neethling joined the room. | 17:36:10 |
