| 02:46 | <MikeSmith> | annevk: yeah I will undo it manually |
| 02:51 | <MikeSmith> | annevk: so I think I undid it, and also disabled that account |
| 02:51 | <MikeSmith> | checking bugzilla, it seems that was the only bug he/she changed |
| 03:11 | <cluelesscoder> | hi, out of curiosity has there ever been a discussion on adding an insertAfter method similar to the insertBefore method to the native DOM API? so that we don't have to manually add the function described at http://stackoverflow.com/questions/4793604/how-to-do-insert-after-in-javascript-without-using-a-library if not using a library |
| 03:17 | <cluelesscoder> | I guess it's not necessary if you figure out the next sibling and insertBefore always |
| 05:28 | <miketaylr> | cluelesscoder: isn't that node.append()? https://dom.spec.whatwg.org/#dom-parentnode-append |
| 07:23 | <annevk_> | cluelesscoder: miketaylr: or just after() |
| 07:25 | <miketaylr> | oh right, nice. |
| 07:32 | <Domenic> | annevk: I don't really see a reason to change the title of Encoding... |
| 07:34 | <annevk> | Domenic: yeah, it seems somewhat clear that all the other encodings are a bit secondary |
| 07:35 | <annevk> | Domenic: I don't see a strong reason to change it, but I also don't really have a strong reason not to (other than consistency with other WHATWG specification names) |
| 07:49 | <Domenic> | Yeah I mean sticking with what already works seems like the best position. No need to change references etc. Changing a title is fairly disruptive. |
| 07:49 | <Domenic> | There's no actual evidence of confusion either this is just feedback from W3C AC Forum upon the PR transition for the fork. |
| 07:53 | <annevk> | Oh I see |
| 07:53 | <annevk> | To be fair, they did give feedback to us, not www-international |
| 08:09 | <annevk> | Domenic: thank you, closed https://github.com/whatwg/encoding/issues/11 |
| 08:59 | <zcorpan> | live webvtt viewer in firefox continually uses CPU which makes my laptop hot and noisy :-( don't know what's up with that |
| 09:38 | <jgraham> | zcorpan: Link |
| 09:38 | <jgraham> | ? |
| 09:44 | <Ms2ger> | https://zcorpan.github.io/live-webvtt-viewer/ |
| 09:49 | <zcorpan> | jgraham: ^ (sorry for delay) |
| 09:50 | <jgraham> | zcorpan: np |
| 09:54 | <jgraham> | zcorpan: Just having it open doesn't seem to use cpu for me. Try the performance inspector in devtools? It's a little hard to figure out what it's on about, but you might see something obvious? |
| 09:56 | <zcorpan> | jgraham: hmmm. seems it happens when editing and then clicking "save to address bar", firefox paints a lot after that |
| 09:59 | <zcorpan> | putting a breakpoint in onhashchange suggests it only runs that once |
| 10:03 | <jgraham> | File a bug? |
| 10:03 | <zcorpan> | yep sure |
| 10:21 | <zcorpan> | https://bugzilla.mozilla.org/show_bug.cgi?id=1221942 |
| 10:27 | <annevk> | mkwst: pretty sure bifurcation and rlbmoz are the same |
| 10:28 | <annevk> | mkwst: and I thought the idea was to just put it in Fetch directly |
| 10:42 | <mkwst> | annevk: I don't want a separate normative document. I do want something I can point agl to, and I don't think he's going to be thrilled with a diff to a spec he's probably never read. :) |
| 10:43 | <annevk> | mkwst: okay |
| 10:43 | <annevk> | mkwst: convincing agl seems worthwhile |
| 10:45 | <mkwst> | annevk: I thought about it a bit on the flight back, and I think I'm convinced. I don't have any time to actually implement an experiment, which is a bit frustrating. |
| 10:45 | <mkwst> | but I'll at least help Richard document it, and start some discussion with folks who care. |
| 10:45 | annevk | wonders what https://twitter.com/mad_p/status/662199914420563968 is about |
| 10:46 | <annevk> | mkwst: we have someone who can implement in Q1 |
| 10:46 | <annevk> | mkwst: Richard assured me he has the relevant powers to make things happen |
| 10:47 | <mkwst> | annevk: Can Richard find someone to work on Chrome too? I'm buried. :) |
| 10:47 | <annevk> | heh |
| 10:49 | <annevk> | mkwst: so, https://github.com/whatwg/fetch/issues/39 |
| 10:49 | <annevk> | mkwst: I want to know whether to kill the entire feature or whether some of it has merit |
| 10:49 | <mkwst> | Looking at it right now, but I have lost any and all context I might once have had. :) |
| 10:50 | <annevk> | mkwst: a lot of the background is https://github.com/slightlyoff/ServiceWorker/issues/412 |
| 10:51 | <annevk> | mkwst: starting from https://github.com/slightlyoff/ServiceWorker/issues/412#issuecomment-58646963 |
| 10:53 | <annevk> | mkwst: in addition to that, we have the possibility of limiting to CORS / same-origin |
| 10:56 | <mkwst> | (sifting through email to find the thread that led me to comment on the bug) |
| 11:00 | <mkwst> | annevk: So, my main concern is with 'only-if-cached'. I think the others are probably fine. |
| 11:01 | <mkwst> | annevk: I don't think CORS helps, as CORS just means that the server gave permission to read the data. It doesn't give the reader permission to know that the data is there to be read. |
| 11:01 | <annevk> | mkwst: yeah, I guess only same-origin would help |
| 11:01 | <mkwst> | annevk: Same-origin means that the reader has server logs to fall back on to determine that the user read the data already. Cross-origin loses that benifit. |
| 11:02 | <mkwst> | Running to a thing. Back in ~30m. |
| 11:02 | <annevk> | mkwst: right, but at least if you restrict to same-origin you cannot use it as a supercookie |
| 11:03 | <annevk> | mkwst: it seems force-cache has similar issues since force-cache plus a timer is effectively equivalent to only-if-cached |
| 11:06 | <annevk> | So yeah, I guess those two should be removed |
| 11:08 | <annevk> | And I guess I should also remove them from the model for now, I don't think any specification relies on them and I don't think we'd want any specification to rely on them |
| 11:15 | <annevk> | Though if force-cache has that problem... So would first doing a request using mode "default" and then doing one with "reload" and timing the difference... |
| 11:16 | <annevk> | Once timing attacks are okay you can probe the cache pretty effectively, and probably more effectively due to these parameters existing |
| 11:17 | <annevk> | So perhaps restricting it to same-origin would still be best... As long as user agents clear that at the same rate as cookies we wouldn't expose anything new |
| 11:17 | <annevk> | JakeA: ^^ |
| 11:22 | <JakeA> | annevk: sounds good to me. In terms of what I've heard developers asking for, they're more interested in bypassing the cache than going cache-only |
| 11:22 | <annevk> | JakeA: it's somewhat annoying that even offering that makes timing attacks easier |
| 11:22 | <JakeA> | Although cache-only would be nice for web fonts, to emulate font-display:optional |
| 11:24 | <JakeA> | annevk: isn't this just as easy with ?blahblah on the end of the URL? |
| 11:24 | <annevk> | JakeA: in practice it might be |
| 11:25 | <annevk> | JakeA: not sure if that's sufficient to convince the security teams |
| 12:02 | <johnme> | annevk: blink folks are asking if we've gotten a TAG review for notifications. I couldn't find one, so shall I go ahead and file one at https://github.com/w3ctag/spec-reviews/issues ? |
| 12:02 | <annevk> | johnme: sure |
| 12:09 | <philipj> | annevk: if you have a strong preference document.URL, now's your chance: https://code.google.com/p/chromium/issues/detail?id=259920 |
| 12:21 | <annevk> | My preference is Punycode since we use ASCII for the path too |
| 12:24 | <mkwst> | annevk: Can I assume that you want https state to move to the document as well? (regarding https://github.com/whatwg/html/pull/273)? |
| 12:25 | <annevk> | mkwst: yes |
| 12:25 | <mkwst> | Ok. :( |
| 12:26 | <annevk> | mkwst: again, I'm sorry |
| 12:26 | <mkwst> | Naah. No big deal. It's bz's fault, really. |
| 12:27 | <annevk> | heh |
| 12:27 | <zcorpan> | philipj: can you explain why region id should be parser-internal only? i've heard feedback that it would be nice to be able to style different regions with css, which makes perfect sense to me |
| 12:27 | <annevk> | I suspect this is fallout from Brendan Eich's document.write() debacle |
| 12:27 | <annevk> | mkwst: what do you think about my cache analysis above? |
| 12:27 | <annevk> | mkwst: and JakeA's remark? |
| 12:28 | <mkwst> | I'm less concerned about timing attacks than I am about 100% reliable queries. |
| 12:28 | <mkwst> | So, yeah, I think your comments are accurate. |
| 12:28 | <mkwst> | But I don't think they're fatal to force-cache. |
| 12:29 | <annevk> | Okay, well, I'm happy to just remove the one problematic one and see what happens when someone tries to ship it |
| 12:29 | <mkwst> | I think that's a reasonable approach. |
| 12:36 | <philipj> | zcorpan: can ::cue-region take an id? |
| 12:36 | <zcorpan> | philipj: not currently |
| 12:37 | <philipj> | OK, and there wasn't any other way to use the ID than to get the region at the time I was thinking about this. |
| 12:37 | <philipj> | In which case just associating them and removing the indirection from the API seemed nice |
| 12:37 | <zcorpan> | ok |
| 12:39 | <mkwst> | annevk: I'm re-reading bz's comments on the CSP list bug again, and I don't think I understand what he wants. I've given you a patch that just moves the thing from Window to Document, but he's suggesting that we can avoid patching `document.open()` and etc. |
| 12:39 | <mkwst> | annevk: I don't see how to do that. |
| 12:47 | <annevk> | mkwst: document.open() doesn't change the document, it only changes the global |
| 12:47 | <annevk> | mkwst: so you can avoid patching document.open() if you store stuff on the document |
| 12:48 | <mkwst> | annevk: Ah, I see. Thanks. |
| 12:48 | <annevk> | mkwst: I think bz was just pointing out the various ways we could go about this and where he'd like to avoid adding complexity |
| 12:48 | <annevk> | mkwst: which to me read that he wanted this on document |
| 12:49 | <mkwst> | Yup, which is fine. I'm happy to do it that way, I just want to give you a patch you'll accept rather than iterating for a few more days. :) |
| 12:59 | <mkwst> | annevk: I'll follow it up with a patch to move HTTPS state. |
| 14:26 | <annevk> | mkwst: note that I left feedback in https://github.com/whatwg/html/pull/273 |
| 14:27 | <annevk> | mkwst: not sure if you saw, given the follow up PRs |
| 14:29 | <mkwst> | Thanks for the ping. How do you stay on top of PRs? I imagine you have more notifications coming in than I do, but I find it hard to know what I ought to be looking at. |
| 14:30 | <mkwst> | annevk: GitHub has randomly chosen to send me some updates to my work email, some to home email, some to chromium.org. I don't get it. |
| 14:30 | <annevk> | mkwst: I'm not sure how, but this one I have as an open tab since you've been working on it today and I've been reviewing it today and I just got back from lunch... |
| 14:31 | <annevk> | mkwst: I only use the web UI for GitHub |
| 14:31 | <annevk> | no email |
| 14:32 | <mkwst> | annevk: I try to use the web UI, but I feel like I'm missing things constantly. *shrug* |
| 14:32 | <mkwst> | Like, this PR doesn't show up in "notifications". Which makes no sense. I have to cli |
| 14:33 | <annevk> | That is sad |
| 14:33 | <mkwst> | I have to click through "Pull Requests", which is fine, I suppose, but I want one place to look at things I need to care about. |
| 14:33 | <annevk> | To be fair, when you push changes and don't add comments I don't think I get notified either |
| 14:33 | <annevk> | But I try to go through outstanding PRs somewhat regularly since it's not nice to keep folks waiting |
| 14:35 | <annevk> | mkwst: about rel=noopener http://logs.glob.uno/?c=mozilla%23content&s=5+Nov+2015&e=5+Nov+2015#c338410 |
| 14:37 | <mkwst> | annevk: Wonderful. I guess I should hop back into #content. |
| 14:38 | <mkwst> | annevk: rel=noopener is straightforward. How do you feel about the window.open pieces of Charlie's old proposal? |
| 14:38 | <mkwst> | annevk: I guess I should just ask bz. :/ |
| 14:39 | <annevk> | mkwst: not sure about those |
| 14:39 | <annevk> | mkwst: we need to credit Scott Beardsley for rel=noopener https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0046.html |
| 14:40 | <annevk> | mkwst: I suspect bz would be fine with such features if he was fine with this one |
| 14:41 | <mkwst> | I guess I should pay attention to whatwg@. :/ |
| 14:42 | <annevk> | mkwst: refresh that earlier URL for more from bz |
| 14:42 | <annevk> | mkwst: discussing window.open() at the end |
| 14:42 | <annevk> | mkwst: you can also join the channel on Mozilla IRC of course |
| 14:48 | <wanderview> | JakeA: do you have some idea when chrome will implement/ship https://github.com/whatwg/fetch/pull/146? |
| 14:48 | <wanderview> | JakeA: would be nice to align our changes if we can to minimize compat issues |
| 15:46 | <mkwst> | annevk: Would you prefer `window.open` to change in the same PR as `rel=noopener`? |
| 15:59 | <annevk> | mkwst: given https://github.com/whatwg/html/issues/313 does it need to change? |
| 16:00 | <annevk> | mkwst: if it's a separate feature, separate might be better, but I can't really see the changes in front of me so use your best judgment I guess |
| 16:00 | <mkwst> | *shrug* It's pretty related. I'll send you a patch, you can tell me to split it up. |
| 16:01 | <annevk> | mkwst: I'm away for a couple hours starting now |
| 16:01 | <JakeA> | wanderview: on leave today and can't reach github for some reason, will pick this up tomorrow |
| 16:01 | <mkwst> | Yup. My day's pretty much over as well. No rush on the review. |
| 16:49 | <bblfish> | @annevk does the fetch api allow one to intercept a 401? |
| 16:49 | <bblfish> | I don't seem to be able to do it, though I think the service worker does. |
| 18:11 | <annevk> | bblfish: in theory, yes |
| 18:11 | <annevk> | bblfish: if you set the window argument to null, iirc |
| 18:11 | <annevk> | bblfish: but this was all defined fairly recently so I'm not sure implementations caught up yet |
| 18:11 | <bblfish> | ah, ok. will try that. |
| 18:12 | <bblfish> | I am noticing that I don't actually seem to get the preflight requests coming to my server. |
| 18:12 | <annevk> | bblfish: there's no preflights same-origin |
| 18:13 | <annevk> | bblfish: fetch(..., { window:null } ) is it, but again, I doubt that's implemented |
| 18:13 | <bblfish> | I have a request from localhost going to joe.example ( both on the same machine, but the domain names are different ) |
| 18:14 | <bblfish> | ok will try with { |
| 18:14 | <bblfish> | headers = { "Accept" = rdfMimeTypes }, |
| 18:14 | <bblfish> | requestCache = RequestCache.reload, |
| 18:14 | <bblfish> | window = null |
| 18:14 | <bblfish> | } |
| 18:14 | <bblfish> | ( that's scalajs ) |
| 18:15 | <bblfish> | what is mode = cors |
| 18:15 | <bblfish> | for ? |
| 18:15 | <annevk> | Reading cross-origin responses that implement the CORS protocol |
| 18:16 | <annevk> | requestCache is not a thing... |
| 18:16 | <annevk> | Not sure if scalajs is really the same as this API if that is a thing... |
| 18:17 | <bblfish> | I have just read through the fetch spec and tried to add the typesafety to your api |
| 18:17 | <bblfish> | https://github.com/read-write-web/rww-scala-js/blob/2874afd344590aa1d147efe63eec2431ad8789c8/src/main/scala/org/scalajs/dom/experimental/Fetch.scala#L307 |
| 18:18 | <bblfish> | so that others developers won't have to keep hunting down typos |
| 18:19 | <bblfish> | so { mode = cors } would allow me to intercept cors answers? |
| 18:21 | <annevk> | bblfish: s/intercept/read/ yes |
| 18:21 | <annevk> | bblfish: and also s/answers/responses/ |
| 18:22 | <bblfish> | ah, nice. So that would allow me to avoid an extra connection for a 401 perhaps by authenticating immediately... |
| 18:22 | <bblfish> | but why is window = null important? Or is it just meant to be called like that from the ServiceWorker ? |
| 18:23 | <bblfish> | ( My ServiceWorker seems to get the 401 ) |
| 18:24 | <caitp> | "any window; // can only be set to null", is presumably why |
| 18:24 | <annevk> | bblfish: if you are invoking things from the service worker and not passing a request through you don't need window = null since it's the default there |
| 18:24 | <annevk> | bblfish: a service worker has no window |
| 18:24 | <bblfish> | yep. Just wondering why it's important to have window = null if it is a JS in a window doing it. |
| 18:24 | <annevk> | bblfish: when you use fetch() in a document environment (or when you pass a request through) it defaults to the window of that document and is the place to show dialogs in |
| 18:25 | <annevk> | bblfish: mostly because that's the default behavior |
| 18:25 | <caitp> | "If init's window member is present and it is not null, throw a TypeError." hah, i'm sure there's a good reason for this but it seems kind of wacky at the moment |
| 18:25 | <bblfish> | ah ok. Thought it might be a security thing |
| 18:25 | <annevk> | caitp: IDL doesn't allow accepting null as the sole value |
| 18:26 | <annevk> | caitp: note that omitting the argument / passing undefined gives you a different behavior |
| 18:26 | <caitp> | yeah, but having it be the sole acceptable value is just kind of weird |
| 18:26 | <annevk> | caitp: we may at some point decide to allow users to pass in different Windows, although it doesn't seem likely |
| 18:27 | <annevk> | caitp: well, maybe from a service worker it is somewhat likely that you'd be able to pass in an existing ClientWindow or some such |
| 18:27 | <annevk> | dunno |
| 18:34 | <bblfish> | well using the 48.0.2555.0 canary (64-bit) and it does not send an options |
| 18:35 | <bblfish> | even though the host is different from the Referrer |
| 18:35 | <bblfish> | Firefox developer edition does not either |
| 18:36 | <bblfish> | I wonder if this is an issue because both are running on localhost. |
| 18:38 | <bblfish> | neither seem to give the expected result on window=null |
| 18:38 | <bblfish> | but that may be me... |
| 18:40 | <bblfish> | ok, so ServiceWorkers are a way out until window=null works reliably then I suppose. |
| 18:41 | <bblfish> | @annevk should I file a bug about the browsers not sending a preflight on my setup? I'll try running my code on another machine first perhaps just to see if that makes the difference. |
| 18:42 | <annevk> | bblfish: it depends, are you actually making a request that warrants a preflight? |
| 18:42 | <caitp> | the options request is sent depending on what is in the request, and where the request is going |
| 18:43 | <bblfish> | It's a GET |
| 18:43 | <annevk> | bblfish: yeah and it seems you only use a safe header, Accept, so you won't trigger a preflight |
| 18:43 | <bblfish> | ah good. |
| 18:43 | <annevk> | bblfish: try set a random header, e.g., bblfish: good times |
| 18:44 | <annevk> | bblfish: you'll get a preflight then |
| 18:44 | <bblfish> | ok, well that's better. I was worried that all this may be extreemly costly in requests |
| 18:45 | <bblfish> | if my code knew the server accepted a WWW-Authenticate for the GET, could I send that and not trigger a preflight? |
| 18:45 | <bblfish> | mhh, the other way aroudn, client sends Authenticate: (I think, was just about to write that code ) |
| 18:46 | <bblfish> | "Authorization" |
| 18:49 | <annevk> | bblfish: that requires a preflight |
| 18:50 | <annevk> | bblfish: https://fetch.spec.whatwg.org/#simple-header is the safelist |
| 18:50 | <caitp> | also depends on the origin you're sending from/talking to, and if it's the same request being sent multiple times, the preflight can be cached |
| 18:51 | <caitp> | if you're testing on local host, it could be that it's not really a corss origin request? |
| 18:54 | <bblfish> | I keep shifting shift-cmd and deleting everything on each reload. |
| 18:58 | <bblfish> | ah yes, this time mozilla sent the preflight. |
| 19:02 | <bblfish> | Yep I get an error in chrome "Fetch API cannot load https://joe.example:8443/2013/card. Request header field authorization is not allowed by Access-Control-Allow-Headers in preflight response." |
| 19:03 | <annevk> | there you go |
| 19:04 | <bblfish> | ok, so I see why ServiceWorkers can be useful here: they can caputre the 401 and authorize. |
| 19:04 | <bblfish> | it's just a pitty that they require the whole application to be reloaded. |
| 19:05 | <bblfish> | it would be nice if all the constants such as modes and all those I have collected in https://github.com/read-write-web/rww-scala-js/blob/2874afd344590aa1d147efe63eec2431ad8789c8/src/main/scala/org/scalajs/dom/experimental/Fetch.scala#L307 |
| 19:05 | <bblfish> | were documented as to their meaning in the fetch spec. |
| 19:06 | <bblfish> | otherwise, thanks for the help. I can try implementing Signature authentication with web crypto now. |
| 19:08 | <bblfish> | will only be able to run my app in bleeding edge browsers in the end though, but well... |
| 19:31 | <axisv> | Hello |