!AGetWbsMpFPdSgUrbs:matrix.org

WHATWG

234 Members
https://whatwg.org/chat — logs: https://matrixlogs.bakkot.com/WHATWG/ — Please leave your sense of logic at the door10 Servers

Load older messages


SenderMessageTime
24 Jan 2022
@andreubotella:mozilla.orgAndreu 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:mozilla.organnevk Luca Casonato: I assume https://github.com/whatwg/spec-factory/pull/35#issuecomment-1019990419 looks okay? 11:20:55
@sideshowbarker:mozilla.orgsideshowbarker
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:mozilla.orgsideshowbarker …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:mozilla.orgsideshowbarkerthe problem is that the Background Fetch spec itself doesn’t seem to state any such requirement11:28:48
@sideshowbarker:mozilla.orgsideshowbarkerI guess it’s possible that Chrome is imposing some additional requirement beyond what’s in the spec11:29:27
@annevk:mozilla.organnevk 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:mozilla.orgsideshowbarkerhaven’t tried that yet but will11:50:01
@sideshowbarker:mozilla.orgsideshowbarkerbut now I wonder, does Mixed Content say anything about fetches for unknown URL schemes from secure contexts?11:53:44
@sideshowbarker:mozilla.orgsideshowbarker I mean, I don’t expect it says anything about the chrome-extension scheme specifically, but maybe something more general 11:54:25
@sideshowbarker:mozilla.orgsideshowbarkerI guess I should just look myself and see11:54:39
@sideshowbarker:mozilla.orgsideshowbarker 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
@aliciamay0614:matrix.orgfrankfromthebeach changed their display name from aliciamay0614 to frankfromthebeach.13:07:01
@annevk:mozilla.organnevk sideshowbarker: well Fetch only allows https://fetch.spec.whatwg.org/#fetch-scheme 13:31:03
@sideshowbarker:mozilla.orgsideshowbarkeryeah 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 case13:33:02
@sideshowbarker:mozilla.orgsideshowbarker * 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 case13:33:22
@lucacasonato:matrix.orgLuca 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
@lucacasonato:matrix.orgLuca CasonatoThanks for getting this landed :-)13:34:43
@annevk:mozilla.organnevk 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:igalia.comMs2ger 💉💉Oh, that's new, is it? Will do14:27:07
@andreubotella:mozilla.orgAndreu Botella (he/they)For Deno, link to https://github.com/denoland/deno/issues/13239, since it's gonna take a while to sort that out14:27:46
@annevk:mozilla.organnevkThanks! (And yeah, today-ish new.)14:28:52
@andreubotella:mozilla.orgAndreu Botella (he/they) (cue Ms2ger 💉💉 insisting on me switching to the compilers team at Igalia 🤣) 14:28:52
@ms2ger:igalia.comMs2ger 💉💉:)14:29:00
@weeb69:matrix.org@weeb69:matrix.org left the room.15:53:22
@arai:mozilla.orgarai joined the room.17:22:04
@mgaudet:mozilla.orgmgaudet

👋 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:mozilla.orgmgaudet 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:mozilla.orgevilpie joined the room.17:28:14
@schalk_neethling:matrix.orgSchalk Neethling joined the room.17:36:10

There are no newer messages yet.


Back to Room List