| 08:48 | <hsivonen> | Why does HTMLLinkElement not have a boolean property "disabled" in the spec but has one in Gecko? |
| 08:53 | <annevk> | hsivonen: tracked by https://github.com/whatwg/html/issues/1081 |
| 08:53 | <annevk> | hsivonen: seems nobody was motivated enough to figure out the mismatch thus far |
| 08:56 | <hsivonen> | annevk: sigh. seemingly simple stuff is complicated |
| 08:56 | <hsivonen> | annevk: thanks |
| 09:11 | <annevk> | hsivonen: JakeA: iirc https://github.com/whatwg/html/issues/3672 is of interest to you |
| 09:11 | <annevk> | yoav_: same |
| 15:10 | <wanderview> | annevk: does From-Origin have any implications for http cache? I guess if a server provides different From-Origin headers on the same URL at different times they would need to either block caching or use a Vary header? |
| 15:12 | <annevk> | wanderview: if we go with my "make it part of CORB" proposal then no |
| 15:12 | <annevk> | wanderview: at least not as CORB is currently specified |
| 15:12 | <wanderview> | annevk: because it would be blocked before it reaches http cahce? |
| 15:12 | <wanderview> | I guess I was thinking CORB and From-Origin checking took place above http cache |
| 15:13 | <wanderview> | actually... it seems From-Origin must be checked above http cache since multiple origins share the http cache |
| 15:15 | <annevk> | wanderview: as currently proposed it's not above the http cache, but maybe we should change that |
| 15:16 | <annevk> | wanderview: it's not entirely clear what the attack angle is though if networking is its own process without scripting |
| 15:16 | <wanderview> | annevk: it seems bad if origin A requests a response with From-Origin:A, it goes into http cache, and then later origin B can get it out of the http cache |
| 15:16 | <annevk> | wanderview: https://github.com/whatwg/fetch/pull/686#issuecomment-387432176 |
| 15:17 | <annevk> | wanderview: how would B be able to obtain a non-masked one though? |
| 15:17 | <annevk> | wanderview: B would just get an empty response if the response had that header |
| 15:18 | <wanderview> | annevk: I'm sorry... what makes it an empty response? |
| 15:21 | <wanderview> | I don't understand why it would be an empty response coming out of http cache if the From-Origin check is done below http cache... if it made it to http cache as a full repsonse, what converts it to empty pulling it out of cache? |
| 15:21 | <annevk> | wanderview: the CORB processing model if it incorporates From-Origin |
| 15:22 | <annevk> | main fetch -> CORB stuff -> service worker / network / cache |
| 15:23 | <wanderview> | annevk: surely that is main fetch -> CORB stuff -> service worker -> CORB stuff -> network/cache... right? |
| 15:25 | <wanderview> | but ok |
| 15:27 | <annevk> | wanderview: if the service worker invokes main fetch again, yeah |
| 15:28 | <wanderview> | annevk: ok, that model makes more sense to me |
| 15:28 | <wanderview> | and the server can avoid issues with differing headers using Vary |
| 15:31 | <annevk> | Domenic: note that I'm not totally opposed to always serialize before processing URLs (some browsers also do it for about:blank), but it does seem a little weird |
| 15:32 | <Domenic> | annevk: hmm I don't really get your point. data:, javascript:, and std: are all cases where you want to process "stuff after the scheme" |
| 15:32 | <annevk> | Domenic: but we could embrace it and just accept things get a little weird with relative URLs and such |
| 15:32 | <Domenic> | URL Standard doesn't have a concept of "stuff after scheme" so you can either serialize + strip leading scheme: or you can try to process path[0] + ? + query + # + fragment |
| 15:33 | <Domenic> | I think there are lots of such URLs, not legacy |
| 15:33 | <Domenic> | E.g. blob is also like that I think? |
| 15:33 | <Domenic> | mailto: |
| 15:33 | <Domenic> | etc. |
| 15:33 | <annevk> | Domenic: the question is whether javascript://somehost/%0Aalert(1) should work or not; same for these other URLs |
| 15:34 | <Domenic> | Hmm I see |
| 15:34 | <annevk> | Domenic: and use them as base URL, etc. |
| 15:34 | <Domenic> | Well the way I'm doing it now is the same as for data: URLs. You parse, then serialize, then strip leading scheme: |
| 15:34 | <annevk> | Domenic: I tend to see that as somewhat problematic that it works |
| 15:34 | <Domenic> | It seems reasonable to me; the alternative is treating these as opaque strings where URL decoding doesn't work. Which is weird if we call them URLs. |
| 15:36 | <annevk> | I think it goes against the spirit of the RFCs somewhat |
| 15:36 | <Ms2ger> | new Promise(resolve => resolve()).then(foo) guarantees that foo is called after the current code has run to completion, right? |
| 15:37 | <annevk> | And it also makes our object-based approach rather convoluted (except we need it for blobs somewhat) |
| 15:37 | <annevk> | Ms2ger: yeah, think so |
| 15:38 | <annevk> | Ms2ger: Promise.resolve().then(foo) also works fwiw |
| 15:38 | <Ms2ger> | Oh, neat |
| 15:44 | <Domenic> | annevk: hmm I don't really understand this spirit of the RFCs thing. |
| 15:44 | <Domenic> | Also maybe I misunderstood. |
| 15:44 | <Domenic> | javascript://somehost/%0Aalert(1) would work if we used URL components (e.g. path[0]). But it wouldn't work if we did serialize-then-strip. |
| 15:45 | <Domenic> | And it seems better (more RFC-ey, even) for it to not work? |
| 15:45 | <annevk> | It does work with serialize-then-strip |
| 15:45 | <Domenic> | how so? |
| 15:45 | <Domenic> | Oh becaues of the // lol |
| 15:45 | <annevk> | It wouldn't work if we aborted if host was non-null |
| 15:45 | <Domenic> | I see |
| 15:46 | <Domenic> | I guess this is probably worth a more general issue discussed with a wider community. Plus maybe API affordances if we figure something out. I think I understand enough to open such an issue now. |
| 15:46 | <annevk> | That'd be great, I was thinking along similar lines |
| 15:47 | <annevk> | We should indeed just enshrine the pattern set by data/javascript and either label it legacy or "this is what we do" |
| 15:47 | <annevk> | E.g., it'd make more sense if the serialize had a way to omit the scheme too for this kind of thing |
| 15:48 | <Domenic> | Yeah exactly |
| 15:48 | <annevk> | Domenic: copy mnot maybe? |
| 15:48 | <Domenic> | good idea |
| 15:48 | <annevk> | biab |
| 16:13 | <Domenic> | Posted https://github.com/whatwg/url/issues/385 |
| 16:35 | <annevk> | \o/ |
| 22:13 | <justJanne> | Whenever someone says again that you can’t just deprecate existing APIs in the browser from one day to another... |
| 22:14 | <justJanne> | ...I’ll link https://arstechnica.com/gaming/2018/05/chromes-autoplay-video-blocker-is-accidentally-killing-web-based-games/ |
| 22:14 | <justJanne> | specifically, Chrome’s WebAudio autoplay restrictions in recent versions breaking tons of sites |
| 22:21 | <laughinghan> | > To get around this, Web-based games now have to actively restart that pre-loaded audio object when the player makes an action to start the game, even if that audio wasn't autoplaying beforehand. |
| 22:21 | <laughinghan> | that's an interesting choice. Is there a Chromium ticket with discussion of why they couldn't go with something less disruptive? |
| 22:23 | <laughinghan> | e.g. enabling the audio object once the player has made one of the actions they've instrumented without requiring restarting the object? |