| 03:10 | <rniwa> | annevk: yt? |
| 03:27 | <wanderview> | rniwa: annevk is on holiday for a few weeks I think |
| 03:35 | <annevk> | đ |
| 03:37 | <rniwa> | I see. |
| 03:37 | <rniwa> | does anyone know about media loading? |
| 04:52 | <annevk> | rniwa: you want to email foolip and JakeA |
| 04:53 | <rniwa> | annevk: ok, thanks |
| 08:41 | <JakeA> | rniwa: I've been looking into this recently, but I'm about to go on holiday for a week. I'm around for the next~5 hours though |
| 08:41 | <rniwa> | JakeA: okay. |
| 08:42 | <rniwa> | JakeA |
| 08:42 | <rniwa> | JakeA: so we have "If a source element is inserted as a child of a media element that has no src attribute and whose networkState has the value NETWORK_EMPTY, the user agent must invoke the media element's resource selection algorithm." |
| 08:42 | <rniwa> | JakeA: what prevents this step from running inside a template element? |
| 08:44 | <JakeA> | rniwa: ah, I've been looking at it from more of a fetch perspective. For HTML integration, I guess foolip will know more. |
| 08:44 | <JakeA> | Sorry! |
| 08:44 | <JakeA> | I don't even know how template prevents img loading off the top of my head |
| 08:45 | <rniwa> | JakeA: ok, thanks |
| 08:48 | <rniwa> | JakeA |
| 08:48 | <rniwa> | JakeA: but surely, there is some choke point for a document without a browsing context from issuing a network request?? |
| 08:54 | <JakeA> | rniwa: not within fetch. It looks like <script> handles this using language like "if src is changed and the script element is [=connected=]" |
| 08:54 | <JakeA> | I guess media should do the same |
| 08:54 | <rniwa> | JakeA: connected doesn't mean it doesn't lack a browsing context |
| 08:54 | <rniwa> | JakeA: a document may or may not have a browsing context |
| 08:55 | <JakeA> | rniwa: when does that occur? Bfcache? |
| 08:56 | <rniwa> | JakeA: or a document in XHR |
| 08:56 | <rniwa> | JakeA: there is a bunch of cases |
| 08:56 | <rniwa> | JakeA: you can have a document in iframe which navigates away from it |
| 08:56 | <rniwa> | there is nothing preventing from scripts to access to the document if the script previously stored a reference to it |
| 08:57 | <rniwa> | I guess it checks https://html.spec.whatwg.org/#concept-n-noscript |
| 08:57 | <rniwa> | in step 11 of https://html.spec.whatwg.org/#prepare-a-script |
| 09:00 | <JakeA> | rniwa: Stylesheets use https://html.spec.whatwg.org/multipage/infrastructure.html#browsing-context-connected |
| 09:01 | <Ms2ger> | rniwa, hmm, on first sight, it does look like the spec misses that case |
| 09:02 | <rniwa> | JakeA: oh neat |
| 09:03 | <rniwa> | Ms2ger, JakeA: it appears to me that source element's processing model doesn't really check any of that :( |
| 09:04 | <JakeA> | I wonder how this works for <img>, since they fetch before being connected. |
| 09:10 | <rniwa> | "In a browsing context where scripting is disabled, user agents may obtain images immediately or on demand. In a browsing context where scripting is enabled, user agents must obtain images immediately." |
| 09:10 | <rniwa> | what a vague statement... |
| 09:11 | <rniwa> | "A user agent that obtains images on demand must update the image data of an img element whenever it needs the image data (i.e., on demand), but only if the img element's current request's state is unavailable. When an img element has experienced relevant mutations, if the user agent only obtains images on demand, the img element's current request's state must return to unavailable." |
| 09:11 | <JakeA> | https://static-misc.glitch.me/dom-img-xhr/ Chrome, Firefox, & Safari fetch once the image is added to the browsing context |
| 09:13 | <rniwa> | JakeA: i guess we'd have to test what happens when img element is inside a template element, etc.. |
| 09:13 | <rniwa> | JakeA: but it would be shitty if any browser fetched it since the whole point of inventing template element is not to do that |
| 09:13 | <JakeA> | rniwa: agreed. But I'm not really familiar with how <template> works. |
| 09:14 | <rniwa> | JakeA: it's just a document without a browsing context |
| 09:14 | <rniwa> | JakeA: what would be interesting is to figure out |
| 09:14 | <rniwa> | whether img is fetched inside a document which has been removed from a frame |
| 09:15 | <JakeA> | I think <img> is the outlier in terms of fetching before it's connected. Although IE does the same with <script> (not sure if Edge does the same) |
| 09:16 | <rniwa> | JakeA: yes, for historical reasons |
| 09:16 | <rniwa> | JakeA: img MUST fetch its resource right away |
| 09:16 | <rniwa> | it's the way we used to pre-fetch images... |
| 09:16 | <rniwa> | g'old JS1.3... |
| 09:17 | <rniwa> | anyhow, it's getting a bit too late for me here in Cupertino |
| 09:17 | <JakeA> | How else could hover effects work? đ |
| 09:17 | <JakeA> | g'night! |
| 09:17 | <rniwa> | JakeA: anyhow, thanks! |
| 18:29 | <domfarolino> | annevk: We've talked a bit before about how impls should be able to discern between `null` and `undefined` for RequestInit's `AbortSignal?` member, however looking at https://heycam.github.io/webidl/#es-dictionary (step 4.1.2), it looks null/undefined are both treated the same, thus indistinguishable? Is that accurate? |
| 20:07 | <TimothyGu> | domfarolino: annevk is on vacation right now I think. But it does seem like null and undefined are treated the same way |
| 20:08 | <TimothyGu> | i.e., the dictionary member is treated as not present |
| 20:13 | <domfarolino> | TimothyGu: ah wasnât sure if he was back yet. Following that logic, it seems that https://github.com/web-platform-tests/wpt/blob/master/fetch/api/abort/general.any.js#L149 shouldnât be a valid scenario would |
| 20:13 | <domfarolino> | would you agree* |
| 20:14 | <domfarolino> | context: https://fetch.spec.whatwg.org/#dom-request step 28 & 30 wouldnât be able to pick up a ânullâ AbortSignal as per WebIDL? |
| 20:16 | <TimothyGu> | domfarolino: I agree with you on this |
| 20:16 | <TimothyGu> | alternatively we could have special handling for nullable types in dictionary |
| 20:17 | <TimothyGu> | but that's definitely a rabbit hole that'll probably prove not worth going down |
| 20:19 | <TimothyGu> | It would be interesting to see how browsers actually behave in the case of this test. |
| 20:19 | <domfarolino> | TimothyGu: Agreed. Would that special handling probably be baked into the Request() constructor, or somewhere in the IDL perhaps? I feel like in the Request constructor it's technically too "late", since the WebIDL conversions should have taken place |
| 20:19 | <domfarolino> | Yeah, I've dug into FF a bit but need to look more |
| 20:19 | <TimothyGu> | Yeah it's gonna have to be in IDL |
| 20:20 | <domfarolino> | đ |
| 20:20 | <domfarolino> | For now I'll open an Fetch issue for discussion, ta |
| 20:26 | <TimothyGu> | domfarolino: interestingly Chrome's IDL codegen doesn't actually treat null as undefined |
| 20:26 | <TimothyGu> | https://cs.chromium.org/chromium/src/out/Debug/gen/third_party/blink/renderer/bindings/core/v8/v8_request_init.cc?gsn=ToImpl&l=258 |
| 20:27 | <domfarolino> | That's because of a change we just made |
| 20:27 | <domfarolino> | So basically peria@ and I discussed that null and undefined should be distinguishable |
| 20:27 | <domfarolino> | However it seems that assumption was wrong |
| 20:27 | <Domenic> | Seems like you'd need to use any |
| 20:28 | <TimothyGu> | Domenic: I don't think any would either in this case actually |
| 20:29 | <Domenic> | Yeah, digging in... |
| 20:29 | <TimothyGu> | since null/undefined conversion happens before type conversion for the member |
| 20:29 | <domfarolino> | Right |
| 20:29 | <domfarolino> | For now in chrome we use any to detect, but likely our ability to distinguish null from undefined is not following WebIDL |
| 20:30 | <domfarolino> | s/detect/detect null |
| 20:33 | <Domenic> | This seems really strange... why are nullable dictionary members allowed anyway... |
| 20:33 | <Domenic> | s/allowed anyway/allowed anyway, if this is the case/ |
| 20:34 | <domfarolino> | That's what I was thinking |
| 20:34 | <domfarolino> | hmmm |
| 20:34 | <Domenic> | I wonder if we broke the spec at some point |
| 20:35 | <Domenic> | Alternately we could try to find if any other nullable dictionary members exist. If not, maybe this is the first time we've run into it. |
| 20:35 | <TimothyGu> | Firefox seems to handle it correctly right now though |
| 20:35 | <TimothyGu> | https://searchfox.org/mozilla-central/source/__GENERATED__/dom/bindings/RequestBinding.cpp#530 |
| 20:36 | <Domenic> | December 2016 /TR/ash spec has the same algorithm |
| 20:39 | <TimothyGu> | Also I'm kinda surprised making the change to distinguish between undefined and null in dictionary members didn't break any existing tests |
| 20:39 | <TimothyGu> | in Chrome |
| 20:39 | <domfarolino> | TimothyGu: Hmm I think FF breaks WebIDL spec though right? It looks like it distinguishes between null/undefined which as er #es-dictionary is incorrect |
| 20:40 | <domfarolino> | TimothyGu: It didn't break any changes because the change was sorta half made. `someDictionary.hasFoo()` still returns `false` when `dict.foo` is `null`, so that's maybe why |
| 20:40 | <TimothyGu> | domfarolino: hm what do you mean FF distinguishes between null/undefined? |
| 20:40 | <TimothyGu> | also ah lol |
| 20:43 | <domfarolino> | TimothyGu: Basically FF passes https://github.com/web-platform-tests/wpt/blob/master/fetch/api/abort/general.any.js#L149 |
| 20:43 | <TimothyGu> | heh |
| 20:45 | <domfarolino> | I assume https://searchfox.org/mozilla-central/source/dom/fetch/Request.cpp#415 evals to true |
| 20:46 | <domfarolino> | But either way, nullable dictionary members seem pretty few and far between. I guess I'll file something on Fetch for now and maybe we can move the discussion to WebIDL? |
| 20:47 | <TimothyGu> | Agreed |
| 20:48 | <TimothyGu> | I know bz used to hack Firefox's idl codegen to check if an IDL feature is used in web platform |
| 20:48 | <TimothyGu> | maybe we could do the same with nullable members? |
| 20:48 | <Domenic> | OK false alarm everyone |
| 20:48 | <Domenic> | V is the dictionary |
| 20:48 | <Domenic> | value is the value |
| 20:49 | <Domenic> | So null/undefined canonicalization only happens for V |
| 20:49 | <Domenic> | Not for value |
| 20:49 | <Domenic> | (credit to bz) |
| 20:49 | <TimothyGu> | ah oops |
| 20:49 | <Domenic> | PR incoming to fix the variable names to not be stupid |
| 20:50 | <domfarolino> | phew |
| 20:50 | <domfarolino> | Thanks lol. cc me plz |
| 20:50 | <domfarolino> | \o/ |