| 03:22 | <Domenic> | annevk: would you be able to find someone from Mozilla to comment on https://github.com/whatwg/streams/pull/1035 for implementer interest? |
| 05:11 | <annevk> | Domenic: I pinged some people from the WebVM team |
| 08:02 | <Ms2ger> | > * ignores issue for four years |
| 08:02 | <Ms2ger> | > it's unfortunate [browser] implemented this change without noticing that this open issue existed |
| 08:07 | <annevk> | Ms2ger: that's a very selective quote given what follows, please do better š |
| 08:07 | <Ms2ger> | Well, the ignoring bothers me more than the comment anyway |
| 08:09 | <annevk> | There's not many specifications without that problem unfortunately |
| 08:10 | <annevk> | Although usually the problems are a bit more involved if they are older |
| 09:31 | <yhirano> | annevk: hi, I have some questions about cachestorage (realted to https://github.com/w3c/ServiceWorker/pull/1516). |
| 09:31 | <annevk> | yhirano: sure |
| 09:31 | <yhirano> | annevk: Is https://w3c.github.io/ServiceWorker/#dfn-relevant-request-response-list the persisted requests and responses? |
| 09:38 | <annevk> | yhirano: my knowledge about the Cache API is a bit limited unfortunately; maybe JakeA can help |
| 09:38 | <annevk> | yhirano: on the face of it that definition doesn't make any sense to me |
| 09:40 | <annevk> | yhirano: I guess I can sorta see what it's getting it and I think you're right about the intent, but this isn't how this ought to be worded |
| 09:41 | <yhirano> | annevk: I see. After thinking about this a bit more I come to think we should rely on response, not the request, because web authors can select arbitrary request and response for cache.put arguments. |
| 09:42 | <yhirano> | annevk: web deves can call cache.put(cors-request, opaque-response) so we shouldn't trust the mode on request for the CORP check. |
| 09:43 | <annevk> | yhirano: I tend to agree |
| 09:43 | <annevk> | yhirano: the CORP algorithm I looked it was mostly looking at the request though |
| 09:44 | <annevk> | I suspect in part because the response's URL list wouldn't have been updated yet, but maybe there's a better way to do this |
| 09:44 | <yhirano> | annevk: that's why I'm resetting mode at https://pr-preview.s3.amazonaws.com/w3c/ServiceWorker/1516/0aceaac...yutakahirano:23a4317.html#cross-origin-resource-policy-check-for-cached-resource-algorithm |
| 09:45 | <yhirano> | annevk: For origin request.origin can be "client" and we don't want to use the string. |
| 09:46 | <annevk> | yhirano: I don't see how resetting mode helps with the CORP algorithm not looking at the response |
| 09:48 | <yhirano> | annevk: https://github.com/whatwg/fetch/pull/1030 adds 'Assert: request.mode either "no-cors" or "navigate"'. |
| 09:49 | <annevk> | yhirano: sure, but there's a larger issue |
| 09:49 | <yhirano> | annevk: The CORP check looks at url, mode, origin and coep (via client) on request. |
| 09:50 | <annevk> | Yes |
| 09:51 | <yhirano> | annevk: For origin and client I thin the relevant settings object works. |
| 09:51 | <yhirano> | annevk: For mode we cannot trust request and I'm using response.type instead. |
| 09:52 | <annevk> | yhirano: I mean, URL is the problem, right? |
| 09:53 | <annevk> | yhirano: but also, I'm wondering if we can restructure the CORP check somehow to make it easier for the Cache API to use, rather than having to more or less abuse a request |
| 09:54 | <yhirano> | annevk: in the fetch spec? |
| 09:54 | <annevk> | yhirano: yes |
| 09:54 | <yhirano> | annevk: i see |
| 09:54 | <yhirano> | annevk: For url I think we can use https://fetch.spec.whatwg.org/#concept-response-url |
| 09:55 | <annevk> | yhirano: yeah, though at that point you shouldn't really clone the bogus request, you should just construct your own, but it ends up looking really weird |
| 09:58 | <yhirano> | annevk: ok I'll modify https://github.com/w3c/ServiceWorker/pull/1516 again. We may want to move the CORP-for-cache algorithm to the fetch spec (https://github.com/whatwg/fetch/pull/1030/). Does that sound OK? |
| 10:03 | <annevk> | yhirano: I think we should take a closer look at what algorithm Fetch should define here |
| 10:04 | <yhirano> | annevk: I'm thinking about having CORP-check-for-cached-response which takes a response and and environment settings object and returns allowed/blocked. |
| 10:04 | <yhirano> | annevk: a response and an environment settings object |
| 10:09 | <yhirano> | annevk: (url, mode, origin, client) is calculated as (response's url, "no-cors", settings object's origin, settings object) |
| 10:15 | <annevk> | yhirano: basically, I think the CORP check is also bogus for responses coming from a service worker |
| 10:15 | <annevk> | yhirano: since you can fake the request there as well |
| 10:19 | <yhirano> | annevk: ah you're right. |
| 10:21 | <yhirano> | annevk: what do you think about giving (url, origin, mode, coep, response) instead of (request, response) to the CORP check? |
| 10:22 | <yhirano> | annevk: ah we need two urls, current url and original url for reporting. |
| 10:29 | <annevk> | yhirano: I would prefer looking into whether response should get a URL sooner |
| 10:30 | <annevk> | yhirano: or URL list, for that matter |
| 10:30 | <yhirano> | annevk: sorry I don't understand your last comment. Can you rephrase it? |
| 10:31 | <annevk> | yhirano: in main fetch step 9 we set a response's URL list, if we do that before we do the CORP check, we don't need to pass it so many things and can instead rely on the response for most of it |
| 10:32 | <yhirano> | annevk: i see thanks |
| 10:33 | <annevk> | yhirano: another I thing that seems weird is that we check response tainting before invoking the CORP check, but how would we ever invoke it with mode being navigate then? Does HTML invoke it directly? |
| 10:33 | <yhirano> | annevk: yes |
| 10:35 | <yhirano> | annevk: please see the 6th step of https://whatpr.org/html/5454/browsing-the-web.html#process-a-navigate-fetch. |
| 10:36 | <annevk> | yhirano: that doesn't check it for redirects |
| 10:38 | <annevk> | yhirano: that also seems to have the problem of the request URL not being the correct source of authority |
| 10:40 | <yhirano> | Redirects are handled in the above while loop, right? |
| 10:41 | <annevk> | yhirano: if a redirect response lacks CORP, it would still continue, afaict |
| 10:42 | <yhirano> | annevk: yeah so we need to move the block to somewhere in the step 5. |
| 10:43 | <annevk> | I'll comment on the PR |
| 10:44 | <yhirano> | annevk: regarding the request url vs response url the navigation case is more difficult than cachestorage |
| 10:46 | <annevk> | yhirano: I think we could use the response URL list as well, but I forgot what document URL a request for /foo that gets a response for /bar ends up with, so I'm not entirely sure |
| 10:50 | <yhirano> | annevk: i'll work on the PRs tomorrow. Thank you very much for your thoughtful comments! |
| 10:52 | <annevk> | yhirano: sounds good, take care |
| 12:28 | <domfarolino> | annevk: can you help me understand your iframe lazyload comment about nondeterminism and the sandbox attr? Do you mean the value of the sandbox attribute could change after load deferral, therefore itās āsnapshotā is taking arbitrarily later? |
| 12:31 | <annevk> | domfarolino: yes |
| 12:32 | <annevk> | domfarolino: see also https://github.com/whatwg/html/issues/4926 |
| 12:33 | <annevk> | domfarolino: (it seems that for referrer policy the right thing would happen in your PR) |
| 12:34 | <domfarolino> | annevk: that and the URL, since it is parsed relative to the node doc before navigating |
| 12:34 | <annevk> | domfarolino: right, that helps with blobs |
| 12:35 | <domfarolino> | annevk: hmm ok interesting. Do you have an idea on what other state could be problematic? |
| 12:35 | <annevk> | domfarolino: any kind of policy that is mutable |
| 12:35 | <annevk> | (this is one of the reasons to oppose <meta http-equiv> policies) |
| 12:36 | <domfarolino> | annevk: I guess a solution could be to defer the load much later (in the navigation algorithm) but Iām not sure how clean thatād be |
| 12:37 | <annevk> | domfarolino: so CSP, base URL |
| 12:37 | <annevk> | domfarolino: yeah, we discussed that last time, that might work, but would also trigger some new issues |
| 12:37 | <annevk> | domfarolino: oh, though I guess we have those here too |
| 12:38 | <annevk> | domfarolino: what if someone navigates the frame while there's a navigation queued in this manner? |
| 12:40 | <domfarolino> | annevk: I think thatās not too problematic. The navigation algorithm would be invoked again, the decision to lazy load, if still true, would just re-observe the element (which is no-op), and when the resumption steps are invoked the navigation continues |
| 12:40 | <domfarolino> | annevk: āso CSP, base URLā. Hmm didnāt we say base URL is fine? |
| 12:42 | <annevk> | domfarolino: we did for images, because we already parsed, but frames can inherit things |
| 12:42 | <annevk> | domfarolino: at least, I think a blob URL frame might do something with the base URL and srcdoc certainly will |
| 12:43 | <annevk> | domfarolino: now for blobs I guess you could make the argument that it should be copied when you create the blob URL |
| 12:43 | <annevk> | so maybe blob URLs don't count as much |
| 12:43 | <annevk> | or at all |
| 12:45 | <domfarolino> | annevk: I donāt think I follow. Independently, I donāt actually know anything about blob URLs, which probably isnāt helping. But I was referring to your comment above āright, that helps with blobsā in response to mine about snapshotting the resolved URL before the navigation algorithm |
| 12:51 | <annevk> | domfarolino: I'm not sure what you mean |
| 12:57 | <domfarolino> | annevk: if an elementās loading gets deferred before its src is parsed relative to the node documentās base URL, and the base URL changes, then the load is subject to those base URL changes which is not good. We solve that with images by first parsing the src relative to the document, then deferring after. I think we do the same for iframes, since we parse the url and set up the request before deferring |
| 12:58 | <domfarolino> | So therefore the resolved URL is known before load deferral, which I think is what we want |
| 13:07 | <annevk> | domfarolino: correct |
| 13:08 | <annevk> | domfarolino: the tricky aspect is that a base URL can also been as a policy as it "inherits" into the framed document in certain cases; that's unique to the iframe scenario |
| 13:10 | <domfarolino> | annevk: I see so youāre saying that by parsing the src early on like the PR does, we donāt solve *all* the problems yet, because the base URL is also taken into account later...hmm |
| 13:11 | <annevk> | correct |
| 13:13 | <annevk> | domfarolino: I do think that some of these nondeterminism issues we could maybe just accept, but need to think a bit more carefully if doing so would prevent any future cleanups |
| 13:14 | <annevk> | domfarolino: in the sense that it's not too different from the user doing an unexpected navigation |
| 13:15 | <domfarolino> | annevk: OK makes sense. I think itās fine to accept them, but will take a closer look at the navigation algorithm earlier. Iād like to avoid touching it a lot as I think the currently solution is pretty clean, but weāll see. |
| 13:15 | <domfarolino> | I guess either way Iāll be touching it a little to ensure that delayed iframes donāt delay the load event |
| 17:07 | <annevk> | domfarolino: thanks; I'll try to think a bit more about what a good minimum viable product would be here and discuss with others at Mozilla; perhaps srcdoc and perfect policy enforcement are indeed too much |
| 17:07 | <domfarolino> | annevk: If you'd like to have a VC with myself and some mozilla folks I'd be happy to do that (partially so I could understand the issues better myself) |
| 17:12 | <annevk> | domfarolino: it's still a bit in the planning phase internally, but I'll keep that in mind, thanks; (happy to chat 1:1 earlier if that can help) |
| 17:14 | <domfarolino> | š |
| 22:21 | <gregwhitworth> | hey folks, I may be missing something but is there something in the spec that defines events that should/shouldn't be fired for an <option> element as I'm getting a different result between gecko/webkit for click event: https://jsfiddle.net/3uh6nfsr/ |
| 22:22 | <gregwhitworth> | Looking here: https://html.spec.whatwg.org/multipage/form-elements.html#the-option-element |
| 22:23 | <gregwhitworth> | it inherits the Iface of HTMLElement which has the element and the global events so I'd assume they'd work. I may be missing a note or link however to limitations or UA allowance of support given the interop issues of <select> |
| 22:53 | <Domenic> | gregwhitworth: what's on the prototype chain doesn't govern what events are fired; you need normative text saying "fire an event". Let me look for some... |
| 22:54 | <gregwhitworth> | Domenic: thanks - I figured this must be defined somewhere |
| 22:54 | <Domenic> | gregwhitworth: ah, click event. It turns out there's nothing in all of web specs that says "when the user clicks their mouse, fire a click event". Much less details tricky questions like hit-testing and whether clicking an option counts as clicking the option or its select or... |
| 22:54 | <Domenic> | So basically this is undefined :( |
| 22:54 | <gregwhitworth> | Domenic: ahhh, ok - cool |
| 22:55 | <gregwhitworth> | thanks |
| 23:02 | <Domenic> | No problem; just wish I had better news for you |
| 23:02 | <gregwhitworth> | Domenic: I'm adding in the event mapping for <select> in Open UI and while this spec of course is about documenting what to tie to "options" (whether HTML Platform or JS impl) I found the interop interesting |
| 23:03 | <gregwhitworth> | Domenic: for what it's worth, gecko isn't consistent - it doesn't fire mouseover for options for example |