| 00:40 | <frewsxcv> | can someone help me understand step 5 here? https://dom.spec.whatwg.org/#dom-childnode-before |
| 00:40 | <frewsxcv> | mainly, "and to parent’s first child otherwise" |
| 00:50 | <frewsxcv> | basically, what am i setting to parent's first child? |
| 01:05 | <Mateon1> | frewsxcv: You set `viablePreviousSibling = (viablePreviousSibling != null ? viablePreviousSibling.nextSibling : parent.firstChild)`, from my understanding |
| 01:06 | <Mateon1> | Maybe set node to what I said |
| 01:06 | <Mateon1> | I don't think so, though. |
| 01:12 | <frewsxcv> | I read "If viablePreviousSibling is non-null, set it to viablePreviousSibling’s next sibling" |
| 01:12 | <frewsxcv> | viablePreviousSibling.next_sibling = viablePreviousSibling |
| 01:12 | <frewsxcv> | but yours makes more sense |
| 01:13 | <frewsxcv> | since mine is basically a recursive assignment |
| 01:14 | <frewsxcv> | i suppose my thinking would have been worded "set it as" |
| 01:20 | <Domenic> | JakeA: for podcasts, is the iTunes store not HTTPS yet? |
| 05:01 | <JakeA> | Domenic: not sure about iTunes, but when we last checked feeds, very little https |
| 05:40 | <Domenic> | JakeA: hmm I kind of thought feeds were all hosted by iTunes these days but now I am doubting myself, maybe iTunes is just a directory. |
| 06:11 | <JakeA> | Domenic: since you're awake, I've made some decent progress on cancelable promises. The remaining sticking point is propagating cancellation through resolved values |
| 06:12 | <JakeA> | Domenic: oh, you replied on github, I should read that first |
| 06:30 | <Domenic> | JakeA: not too much substance in my reply really. |
| 06:30 | <Domenic> | JakeA: feel free to open more issues or prod me more. Was excited to look at the commit logs. |
| 06:38 | <JakeA> | Domenic: I'm on leave next week, so will write up remaining issues. Cheers! |
| 06:38 | <Domenic> | bah, you europeans and your vacationing |
| 06:38 | <Domenic> | meanwhile I end up in Japan during 4th of July so I miss those two days off |
| 07:05 | <annevk> | JakeA: so... did you discuss network-spawned dialogs with sleevi? |
| 07:07 | <annevk> | https://github.com/whatwg/dom/issues/49 spam? |
| 07:07 | <JakeA> | annevk: I chatted to him mostly about aborting, but he's in the UK today so we might be able to rope him in if he isn't busy with other stuff. |
| 07:09 | <annevk> | It seemed to me that his concerns around that were about dialogs mostly, but I might be mistaken |
| 07:10 | <JakeA> | annevk: he was also worried about aborting, because we had a security issue around that recently, but it's been patched |
| 07:11 | <JakeA> | (will post a ticket for that if I can find it and it's public) |
| 07:11 | <JakeA> | annevk: as for dialogs, he just wants to know where to surface http auth etc if the request comes from a SW |
| 07:14 | <annevk> | JakeA: if it's not public, can you copy me? Might be helpful guidance in our vetting work |
| 07:14 | <annevk> | JakeA: right, so you know fetch() disables HTTP auth? |
| 07:15 | <JakeA> | annevk: I didn't. Didn't XHR allow it? |
| 07:16 | <annevk> | JakeA: sure, but XHR did lots of silly things, we wanted to make a better XHR, one of the things includes not showing UI by the browser |
| 07:17 | <annevk> | (and XHR is a bit more complicated than just allow, e.g. cross-origin or with supplied credentials it would not) |
| 07:19 | <JakeA> | annevk: I'm guessing there's nothing in a request object that can change that? So a SW that does event.respondWith(fetch(event.request)) would break |
| 07:19 | <annevk> | right |
| 07:19 | <annevk> | It also breaks referrer at the moment, and maybe some other things |
| 07:19 | <annevk> | And redirects as we established |
| 07:21 | <annevk> | A thing that's not addressed currently is TLS client auth |
| 07:22 | <annevk> | Which I think ideally would also not show UI, but according to sleevi that might break some use cases. However, I wonder if we can provide a programmatic API perhaps it might be okay... |
| 07:23 | <JakeA> | annevk: sorry for slow replies, train is crawling slowly towards London through various connectivity black holes |
| 07:24 | <JakeA> | annevk: is the UI case where the browser asks the user to select a cert? |
| 07:24 | <annevk> | Ah okay, I can do something else for a bit first |
| 07:24 | <annevk> | Yes |
| 07:24 | <annevk> | I think that's basically it, I don't fully understand the protocol involved I'm afraid or where it is defined |
| 07:27 | <JakeA> | annevk: I'll see what I can dig up and report back in 30 mins. I'd like to check we're doing the right thing with HTTP auth. It could just be that more of a case for event.default |
| 07:31 | <annevk> | Note that what made event.default() notoriously hard was the idea of it handing back something to the service worker. Which makes it serve two clients at once. |
| 08:02 | <annevk> | JakeA: what prompted the client.fetch() idea? |
| 08:02 | <annevk> | JakeA: and what does it mean? |
| 08:03 | <JakeA> | annevk: I was thinking of how a request could be associated with a window client, so there was a place to show any required UI |
| 08:04 | <JakeA> | and if there was no associated window client, and a UI was required, the request would fail |
| 08:04 | <JakeA> | so event.client.fetch(event.request) could show cert or http auth UI in the client, if the client was a window |
| 08:05 | <JakeA> | It'd be easier if the client was part of the request, but that's tricky when it comes to caching |
| 08:06 | <annevk> | This seems tricky because it's not clear who is initiating the fetch and what it means in terms of referrer etc. |
| 08:07 | <annevk> | Hmm |
| 08:08 | <JakeA> | annevk: isn't referrer set when the request is constructed? |
| 08:08 | <JakeA> | ahh ok, that happens later |
| 08:09 | <annevk> | JakeA: also, request is constructed when fetch() is invoked |
| 08:09 | <annevk> | JakeA: referrer is one of the things that's not maintained at the moment |
| 08:09 | <annevk> | JakeA: we'd basically have to allow referrer to be set to any same-origin URL and nobody has okayed that idea yet that I know |
| 08:11 | <annevk> | (Presumably because nobody else has been thinking about referrer in the context of service workers...) |
| 08:13 | <JakeA> | annevk: if an element makes a request for an image, a request is made with the css url as referrer. Is that not reflected in event.request? |
| 08:14 | <annevk> | JakeA: I can't quite parse that statement |
| 08:14 | <JakeA> | yeah that was bad, let me try again |
| 08:14 | <annevk> | JakeA: but, event.request does reflect the referrer, it is however not passed on to fetch() in anyway, fetch() uses the referrer from the environment |
| 08:15 | <annevk> | any way*? |
| 08:16 | <JakeA> | annevk: ahh ok, so could we allow fetch to use the request's referrer, but put restrictions on when referrer can be set in manually constructed requests? |
| 08:21 | <annevk> | JakeA: my idea was that we'd allow referrer to be set to any same-origin URL |
| 08:22 | <annevk> | JakeA: if you can take referrer from a Request object you can basically get any same-origin URL anyway |
| 08:26 | <JakeA> | annevk: I guess there isn't the concept of a request having headers but you can't see them with JS? |
| 08:27 | <annevk> | JakeA: I think all forbidden headers are set post-service-workers in the network layer |
| 08:28 | <annevk> | JakeA: what are you thinking of? |
| 08:32 | <JakeA> | annevk: "if you can take referrer from a Request object you can basically get any same-origin URL anyway" - so if my page's CSS, on another origin, makes a request for a background image, I can't see the referrer? |
| 08:33 | <annevk> | JakeA: s/see/set/? |
| 08:34 | <JakeA> | annevk: see, as in event.request in the SW |
| 08:35 | <JakeA> | if I intercept the request for my CSS |
| 08:35 | <JakeA> | I should just test it… |
| 08:35 | <annevk> | Cross-origin CSS seems like a major security hole... |
| 08:35 | <annevk> | If A embeds cross-origin CSS B, it should not be able to tell what B is fetching... |
| 08:35 | <annevk> | That violates the same-origin policy... |
| 08:36 | <annevk> | Did we really not think of this? |
| 08:36 | <JakeA> | annevk: you can get that information from computed styles |
| 08:36 | <annevk> | That is not at all the same |
| 08:36 | <annevk> | Not by a long shot |
| 08:37 | <JakeA> | no? |
| 08:37 | <annevk> | There's a reason cross-origin CSSOM requires CORS |
| 08:37 | <annevk> | No |
| 08:37 | <JakeA> | annevk: what does it expose? |
| 08:38 | <annevk> | E.g. if that stylesheet uses credentials or relies on firewall IP-based authentication it could expose tokens in images it fetches |
| 08:39 | <JakeA> | annevk: that wouldn't show up in computed styles? |
| 08:39 | <annevk> | With getComputedStyle you need to know where to look |
| 08:39 | <annevk> | And getComputedStyle wouldn't e.g. work with tokens in CSS subresources |
| 08:40 | <JakeA> | annevk: by subresources you mean @import? |
| 08:40 | <annevk> | Yeah |
| 08:41 | JakeA | goes to check what resource timing API does here |
| 08:43 | <annevk> | Not sure that group has done their vetting carefully |
| 08:44 | <Ms2ger> | Hah |
| 08:45 | <annevk> | TabAtkins: thanks, seems like it's breaking a great number of specifications, e.g. can't update Notifications API either |
| 08:48 | <JakeA> | annevk: so resource timing does expose requests from cross-origin CSS |
| 08:48 | <annevk> | o_O |
| 08:49 | <JakeA> | lemmie check it's not just Chrome… |
| 08:50 | <JakeA> | yeah, Firefox exposes it too |
| 08:50 | <JakeA> | http://jakearchibald.com/ & performance.getEntriesByType('resource').map(obj => obj.name) |
| 08:50 | <annevk> | https://github.com/slightlyoff/ServiceWorker/issues/719 |
| 08:55 | <annevk> | JakeA: so FWIW, if we can't go the API route for TLS client auth we need something like passing a reference to a client to fetch() |
| 08:55 | <annevk> | JakeA: perhaps each worker (including service workers) should simply hold a reference to the "prominent browsing context" (or null) and pass that along |
| 08:57 | <annevk> | JakeA: and I guess if we do that, we'd solve the "no-cors" http thing by banning http URLs if that's null (and global's origin is secure, to not affect dedicated/shared workers) |
| 08:58 | <JakeA> | annevk: just before we move on from the CSS thing… the CSS make the request (bg img, @import) in the context of the page (it isn't its own client), so isn't it reasonable for that to be visible to the page owner? What about a cross-origin script doing new Image(url)? |
| 08:58 | <annevk> | JakeA: and perhaps that check should be in mixed content even, but I'll file an issue against Fetch for now, depending on that HTTP auth issue |
| 09:01 | <annevk> | JakeA: a cross-origin script cannot be sure that the things it invokes have not been meddled with |
| 09:05 | <JakeA> | Ouch, pretty bad Chrome bug http://musalbas.github.io/address-spoofing-poc/ |
| 09:08 | <JakeA> | actually you can't interact with the page so it's not as bad as I thought |
| 09:08 | <JakeA> | but still |
| 09:09 | <JakeA> | annevk: "prominent browsing context" would be either the focused window, a visible window, any window, or null? (in that order of preference?) |
| 09:10 | <annevk> | JakeA: yeah, something like that I guess |
| 09:11 | <JakeA> | I suppose as I developer I could potentially predict the outcome by looking at clients.matchAll |
| 09:11 | <annevk> | JakeA: alternatively we could give the developer control over the window |
| 09:15 | <JakeA> | annevk: that's how I came to client.fetch |
| 09:16 | <annevk> | JakeA: I don't think client.fetch makes sense since you'd need to branch your code depending on what you anticipate the response will be |
| 09:16 | <annevk> | JakeA: and that API suggests other things to me, like the client will actually run the fetch, meaning it would go through the service worker again, or some such |
| 09:17 | <JakeA> | annevk: it'd be 'neater' if it were part of the request. We've gone back & forward on where "client" sits. Because of caching it feels like it shouldn't be part of the request object |
| 09:18 | <JakeA> | annevk: true, I thought "client isn't part of the storable request, but it's part of the execution of the request", which is when I tried to build the association between the client & the fetching |
| 09:19 | <JakeA> | annevk: here's that header truncation issue https://code.google.com/p/chromium/issues/detail?id=244260 |
| 09:19 | <annevk> | Depending on the outcome of that issue and how flexible this needs to be, setting a browsing context might not even be exposed... |
| 09:23 | <JakeA> | annevk: which issue? |
| 09:23 | <annevk> | 119 |
| 09:24 | <JakeA> | ahh gotcha |
| 09:28 | <JakeA> | annevk: I think your "any origin window" idea is good enough. Will write up the options on that ticket |
| 09:28 | <JakeA> | will get someone to look at that CSS CORS issue too |
| 09:29 | <annevk> | We still need to figure out how to update Fetch et al to catch those network-generated dialogs and surface them |
| 09:29 | <annevk> | But baby steps, I guess |
| 09:29 | <annevk> | I would prefer though that fetch() by default generates no UI still... |
| 09:29 | <annevk> | And ideally it never does and if you rely on HTTP auth you just implement it yourself (you can with fetch()) |
| 09:30 | <annevk> | And if you rely on TLS client auth we need to think of something new... But maybe that one isn't feasible |
| 09:45 | <annevk> | JakeA: another big problem with SW is that we haven't rewritten all the features that should use Fetch, but currently invoke something else |
| 09:45 | <annevk> | JakeA: this makes it very unclear how they should work and handle certain types of responses |
| 09:46 | <JakeA> | annevk: yeah, there's some translation going on, so potentially wrong assumptions made |
| 09:47 | <annevk> | Well and most specs still assume the authority is with the request, whereas we shifted it to be on the response |
| 09:47 | <annevk> | Which is a pretty big shift |
| 10:40 | <annevk> | jgraham: https://critic.hoppipolla.co.uk/r/4453 |
| 10:40 | <annevk> | hallvors: ^^ |
| 12:31 | <Ms2ger> | Is there supposed to be a difference between "Let source be the browsing context that contains the Document object with which subject in question is associated." and "let target be the browsing context that subject itself is in." in https://html.spec.whatwg.org/multipage/semantics.html#following-hyperlinks-2 ? |
| 12:32 | <annevk> | Ms2ger: I think the answer is no |
| 12:33 | <annevk> | Ms2ger: it would be clearer if target were set to source |
| 12:33 | <Ms2ger> | Yeah |
| 12:33 | <Ms2ger> | I'd suggest that, but without an editor... |
| 12:34 | <annevk> | Ms2ger: there's a bunch of prose problems there |
| 12:34 | <Ms2ger> | Unsurprisingly :) |
| 12:36 | <annevk> | Ms2ger: could at least file a bug |
| 12:47 | <SimonSapin> | Is there a much content relying on application/xhtml+xml ? (Should Servo try to support it at all?) |
| 12:47 | <annevk> | It's not exactly hard, is it? |
| 12:49 | <Ms2ger> | We don't support XML yet :) |
| 12:50 | <Ms2ger> | But there's an XML5 parser now |
| 12:51 | <annevk> | Isn't that enough? |
| 12:51 | <gsnedders> | I wonder how much XML5 will break? |
| 12:51 | <Ms2ger> | Glue :) |
| 12:51 | <annevk> | It shouldn't really break anything, but who knows |
| 12:52 | <SimonSapin> | my point is that while we may wanna try XML5 for SVG and some other things that require an XML parser, maybe we should still not support XHTML |
| 12:53 | <annevk> | If you're going to have an XML parser, you should just parse everything +xml with it and not make exclusions |
| 12:55 | <SimonSapin> | that’s… RFC 3023 ? |
| 12:58 | <annevk> | https://tools.ietf.org/html/rfc7303 these days |
| 14:25 | <annevk> | JakeA: so the truncation issue sleevi mentioned is actually bigger when we introduce streams / cancel |
| 14:26 | <annevk> | JakeA: it puts an attacker in control of the contents of "no-cors" resources |
| 14:26 | <annevk> | JakeA: which is problematic |
| 14:27 | <annevk> | Well, maybe stream-wise those will be opaque so you don't get a stream... But there might be some other angle... But cancelation-wise the concerns still apply I think... |
| 14:29 | <JakeA> | annevk: yeah. That specific issue was down to Chrome not parsing headers properly, but maybe there are other security-sensitive formats that don't have a delimiter? |
| 14:31 | <JakeA> | annevk: anything you can do with .cancel() could happen by going offline. So if it's a security issue it's already a security issue, just whether it happens accidentally or deliberately. |
| 14:32 | <annevk> | JakeA: well, that seems somewhat absurd |
| 14:33 | <annevk> | JakeA: an attacker has control over cancel() and can easily try it many times without requiring the user to do anything special |
| 14:36 | <JakeA> | annevk: agreed. It makes the highly unlikely quite possible, but it doesn't make the impossible possible. |
| 14:37 | <annevk> | I guess it also depends on how we handle the cancelation in Fetch |
| 14:46 | <TabAtkins> | annevk: Looking into the issue today, but remember you can always force-generate. |
| 14:52 | <gsnedders> | "input[type=hidden i]" — am I missing something? what's that i for? |
| 14:56 | <TabAtkins> | Marks the value as matching CI |
| 15:11 | <annevk> | ASCII case-insensitive* |
| 15:47 | <JakeA> | Domenic: I've made a couple of mistakes in my latest cancelable promise commits, so don't worry about all the breakages. Will fix. |
| 16:12 | <annevk> | jochen__: any ETA on working on Referrer again? |
| 16:32 | <BigPants> | I don't mind standing every dayyyyyy |
| 16:32 | <BigPants> | out on your corner in the pouring raaaaain |
| 16:32 | <BigPants> | look for the girl with the broken smile |
| 16:32 | <BigPants> | ask her if she wants to a whiiiile |
| 16:33 | <BigPants> | AND SHE WIIIIILL BE LOOOOOOOVED |
| 16:33 | <BigPants> | Good channel for that. Totally meant it for another :P |
| 16:51 | <caitp> | well friday is as good a day as any for irc karaoke |
| 16:52 | <BigPants> | I should definitely have picked a cooler song to accidentally belt out though |
| 16:52 | <caitp> | the temptations is always a good pick |
| 17:24 | <jochen__> | annevk: i'm working on it non-stop! |
| 17:24 | <jochen__> | annevk: what's up with it? |
| 20:49 | <cvrebert> | Can someone please remove X-UA-Compatible from https://wiki.whatwg.org/wiki/PragmaExtensions ? It became an official pragma: https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-x-ua-compatible |
| 22:40 | <jwalden> | peoples! if I were unsure whether getBoundingClientRect().top could ever be -0, do people think it'd make more sense to file the bug on getBoundingClientRect, or on DOMRect? |