| 01:08 | <MikeSmith> | Domenic, for botie, I think you currently need to use "inform" instead of "tell" (I'll try to hack my copy of its source to add support for "tell", or maybe it's already been added upstream and I just need to pull it) |
| 04:50 | <MikeSmith> | botie: tell Domenic botie now understands "tell" |
| 04:50 | <botie> | will do |
| 05:29 | <annevk> | TabAtkins: https://fetch.spec.whatwg.org/#dom-global-fetch uses that style |
| 05:29 | <annevk> | TabAtkins: https://storage.spec.whatwg.org/#dom-storagemanager-requestpersistent does too |
| 05:30 | <annevk> | TabAtkins: given that "in parallel" is defined I don't think it matters much |
| 05:41 | <annevk> | Domenic: I can't assign issues to TabAtkins so I don't think that works |
| 05:41 | <annevk> | Domenic: we'd have to actually give contributors access to a set of repositories for that |
| 05:50 | <TabAtkins> | annevk: Of course it matters! It doesn't matter if there's a link to the full meaning if the plain English reads completely wrong. |
| 06:00 | <annevk> | TabAtkins: yeah, I guess we disagree on the plain English reading wrong |
| 06:10 | <TabAtkins> | At least in my ideolect, "Do the following Xs in parallel" means that they'll all execute at the same time. (Not that they'll run in series, in parallel with the surrounding context.) |
| 06:12 | <annevk> | In that case "Run the remaining Xs in parallel" would mean the same thing |
| 06:13 | <annevk> | So neither would be clear with such an interpretation |
| 06:19 | <TabAtkins> | Which is why I'm not suggesting either. There's another phrasing, used in Font Loading, which isn't possible to misunderstand. |
| 06:25 | <annevk> | Well, except it doesn't define "asynchronously" and we've had a bunch of concerns raised over the word "asynchronous" which is why it's "in parallel" (and is somewhat defined) now |
| 06:26 | <annevk> | You also update internal slots from asynchronous thread which seems all kinds of wrong |
| 06:26 | <annevk> | an* |
| 06:47 | <annevk> | philipj: I was thinking, we could also restrict requestFullscreen() on <iframe> by doing an inclusive ancestor check for <iframe> in the ready check, but I guess now Microsoft ships an "iframe fullscreen flag" we should just go with that |
| 06:47 | <annevk> | philipj: also, is it a problem the specification does not deal with <frame>, <object>, and <embed> in some way? |
| 06:48 | <annevk> | I guess those don't support allowfullscreen |
| 07:08 | <philipj> | annevk: I would be quite happy just ignoring the iframe.requestFullscreen() followed by elementInIframe.requestFullscreen() problem |
| 07:08 | <philipj> | I do wonder if it's been an issue in reality |
| 07:08 | <annevk> | Unless my fix is wrong, it does seem relatively easy to fix |
| 07:09 | <philipj> | annevk: I don't think <frame> and friends matter, there was support in WebKit/Blink that was removed, |
| 07:09 | <philipj> | I have seen one bug report where the reason fullscreen didn't work was because of <frame>, though |
| 07:10 | <philipj> | annevk: fixing it with a flag is fine too, since apparently Microsoft was concerned enough to invent their own solution without telling anyone |
| 07:12 | <annevk> | philipj: did you ever look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=16502? |
| 07:13 | <annevk> | philipj: yeah, my thinking was that since they went through the trouble of implementing that and telling us about it (somewhat belatedly) it's okay for us to accept the cost this one time |
| 07:13 | <philipj> | annevk: I have seen that bug, but am not sure what to make of it. |
| 07:13 | <annevk> | philipj: although if they keep doing it that way I won't be as nice about it I think |
| 07:14 | <annevk> | philipj: I guess I'll wait to see if the Presentation API folks have anything to say |
| 07:14 | <philipj> | annevk: Trying to close all Bugzilla bugs are you? |
| 07:14 | <annevk> | Yeah, was thinking of marking the other one MOVED |
| 07:14 | <annevk> | but I guess I can wait a little longer, there's no particular rush |
| 07:15 | <philipj> | Yep |
| 07:18 | <philipj> | annevk: it might interest you to know that there's something weird going on with optional arguments and addEventListener() |
| 07:18 | <philipj> | All of the arguments are optional in Blink, an attempt to fix it a long time ago was reverted due to something breaking, and now the use counters don't look very promising. |
| 07:19 | <philipj> | I don't suppose you've seen any reports in Gecko about this? |
| 07:22 | <annevk> | philipj: nope |
| 08:02 | <MikeSmith> | philipj: a servo guy who was trying to run the wpt DOM ChildeNode tests today was wondering why https://codereview.chromium.org/1234813003/ was reverted |
| 08:03 | <MikeSmith> | (the related wpt tests came from blink upstream, from that changeset) |
| 08:03 | <MikeSmith> | that review cites https://code.google.com/p/chromium/issues/detail?id=509461 |
| 08:04 | <Ms2ger> | @@unscopeables? |
| 08:04 | <MikeSmith> | philipj: but I get a 403 trying to view that bug so I assume it's a security issue |
| 08:06 | <philipj> | MikeSmith: it introduced a crash which is being fixed, not a problem with the spec if that's the concern |
| 08:07 | <MikeSmith> | philipj: ah yeah maybe he had been wondering if it was spec issue |
| 08:08 | <MikeSmith> | anyway thanksーI'll pass on the info if/when I chat with him |
| 08:08 | <philipj> | MikeSmith: np |
| 08:12 | <frewsxcv> | Thanks for the info philipj |
| 08:12 | frewsxcv | is the 'servo guy' |
| 08:13 | <philipj> | frewsxcv: are Nodes refcounted in Servo or what's the general story for keeping them alive across an event dispatch that may run GC? |
| 08:13 | <Ms2ger> | Garbage collection! |
| 08:14 | <Ms2ger> | https://github.com/servo/servo/blob/7235500db6778371abe1d1f727a6d0b24205d5c5/components/script/docs/JS-Servos-only-GC.md |
| 08:14 | <Ms2ger> | Not entirely up-to-date (which I should fix), but fairly |
| 08:15 | <philipj> | Then you will not have the particular crash we did :) |
| 08:16 | <Ms2ger> | We should be entirely safe :) |
| 08:16 | <philipj> | I presume that having the equivalent of a this pointer on the stack will also protect it from GC? |
| 08:16 | <Ms2ger> | Were those mutation events? |
| 08:16 | <frewsxcv> | Last words by every software developer... |
| 08:16 | <Ms2ger> | Yeah |
| 08:16 | <philipj> | Ms2ger: I don't remember, but seems likely. |
| 08:16 | <philipj> | mutation events FTW |
| 08:17 | <Ms2ger> | Fortunately we don't have those either :) |
| 08:18 | <philipj> | Ms2ger: Feel like removing them in Gecko? |
| 08:18 | <MikeSmith> | wow https://github.com/servo/servo/blob/7235500db6778371abe1d1f727a6d0b24205d5c5/components/script/docs/JS-Servos-only-GC.md is nice stuff |
| 08:18 | <philipj> | UseCounter says no: https://www.chromestatus.com/metrics/feature/timeline/popularity/144 |
| 08:18 | <Ms2ger> | Ohgodno |
| 08:19 | <MikeSmith> | sad |
| 08:20 | <MikeSmith> | how high those numbers are stil |
| 08:21 | <philipj> | That's the highest of them, but even the lowest isn't negligible: https://www.chromestatus.com/metrics/feature/timeline/popularity/146 |
| 08:24 | <MikeSmith> | doubly sad |
| 08:24 | <MikeSmith> | wait but that's below 0.03 at least |
| 08:26 | <MikeSmith> | also JS-Servos-only-GC.md is nicely worded |
| 08:26 | <MikeSmith> | Ms2ger: who wrote that? |
| 08:27 | <MikeSmith> | "Josh Matthews and Keegan McAllister" |
| 08:27 | <Ms2ger> | Yep |
| 08:27 | <Ms2ger> | With a little editing from me, but mostly them |
| 08:27 | <MikeSmith> | ok |
| 08:27 | <MikeSmith> | good on you as well then |
| 08:29 | <Ms2ger> | Maybe I should finish it toay |
| 08:41 | <hugoh> | window move up |
| 08:42 | <Ms2ger> | Hey! Where'd my window go? |
| 08:43 | <hugoh> | sorry! forgot the / |
| 10:00 | <annevk> | philipj: we might be able to change mutation event timing |
| 10:00 | <annevk> | philipj: e.g. give them the same timing as custom element callbacks |
| 10:18 | <smaug____> | except DOMNodeRemoved |
| 10:19 | <annevk> | smaug____: what do you mean? |
| 10:19 | <annevk> | smaug____: note that DOMNodeRemoved has much less usage too |
| 10:19 | <smaug____> | DOMNodeRemoved happens before the mutation |
| 10:19 | <annevk> | smaug____: btw, I can't get blur to dispatch at all in Gecko for removed nodes |
| 10:20 | <smaug____> | known issue, IIRC |
| 10:20 | <annevk> | smaug____: sure, per "spec" most of them fire at rather problematic times |
| 10:20 | <smaug____> | though |
| 10:20 | <smaug____> | hmm |
| 10:20 | <smaug____> | though, we do have code which should trigger blur |
| 10:21 | <smaug____> | annevk: so the plan is now to have sync ctors? |
| 10:21 | <smaug____> | for custom elements? |
| 10:21 | <annevk> | smaug____: <p>x<input onblur=alert(1) onfocus=this.parentNode.remove()> is my test |
| 10:21 | <annevk> | smaug____: we don't have a plan yet |
| 10:22 | <smaug____> | annevk: could you file a bug. CC enndeakin too |
| 10:22 | <annevk> | smaug____: Google would really like to avoid more synchronous JavaScript during DOM and editing algorithms |
| 10:22 | <smaug____> | right |
| 10:23 | <annevk> | smaug____: so the current plan is exploring whether blur and beforeunload can be made to dispatch using custom element callback timing |
| 10:23 | <Ms2ger> | I don't think we'd mind that either |
| 10:23 | <smaug____> | I was also thinking that maybe we could postpone blur/beforeunload happening during range operations to happen on nanotask |
| 10:23 | <annevk> | (which is better than script runners) |
| 10:23 | <smaug____> | and selection operations would be a nano task or something |
| 10:23 | <annevk> | right, nanotask |
| 10:23 | <annevk> | the thing that doesn't run during compound range operations either |
| 10:24 | smaug____ | doesn't know what is the difference between "custom element callback timing" and script runners |
| 10:24 | <annevk> | smaug____: DOM component? |
| 10:24 | <annevk> | smaug____: afaik script runners run during a single range operation |
| 10:24 | <annevk> | smaug____: nanotask is always at the end of an IDL method or attribute |
| 10:25 | <smaug____> | script runners run when the outermost script blocker goes away from the stack |
| 10:25 | <annevk> | I don't know what that means |
| 10:25 | <smaug____> | there can be nested script blockers |
| 10:26 | <smaug____> | In C++ you have ScriptBlocker object on stack. When it is created, scriptblocking level is increased |
| 10:26 | <smaug____> | when that object is deleted, level is decreased |
| 10:26 | <smaug____> | and when level becomes 0, scriptrunners run |
| 10:26 | <annevk> | I understand that much, but it's unclear whether they can run during https://dom.spec.whatwg.org/#dom-range-extractcontents for instance |
| 10:26 | <smaug____> | those script runners which were posted while the level was != 0 |
| 10:27 | <smaug____> | currently yes |
| 10:27 | <annevk> | right, which makes them less safe than nanotasks |
| 10:27 | <smaug____> | annevk: but we could effectively put a scriptblocker to selection/editing level code |
| 10:27 | <annevk> | not sure why we keep revisiting this discussion :-) |
| 10:27 | <smaug____> | scriptblockers are nanotasks |
| 10:28 | <annevk> | not if they run during an IDL block |
| 10:28 | <smaug____> | well, in gecko we'd just put scriptblock in the idl block then |
| 10:28 | <smaug____> | scriptblocker |
| 10:29 | <smaug____> | sure, currently ScriptBlockers are used somewhat ad hoc in Gecko |
| 10:29 | <annevk> | once you've made that change we can start calling them nanotasks too |
| 10:29 | <annevk> | until that time the distinction is useful |
| 10:29 | <smaug____> | sure |
| 10:31 | <annevk> | smaug____: https://bugzilla.mozilla.org/show_bug.cgi?id=1187848 |
| 10:32 | <smaug____> | thanks |
| 10:33 | smaug____ | wonders how this nanotask approach will deal with DOMNodeRemoved |
| 10:46 | <annevk> | smaug____: https://github.com/whatwg/dom/issues/57 has some details from Edge |
| 10:46 | <annevk> | smaug____: seems they do some other things for tree operations compared to other browsers |
| 11:06 | <philipj> | annevk: looks like custom element callbacks are kind of like microtasks but their processed at the boundary between native and script? |
| 11:06 | <annevk> | philipj: only the return boundary |
| 11:07 | <annevk> | philipj: the nickname nanotasks came from that being possible multiple times within a microtask |
| 11:08 | <philipj> | s/their/they're/ unforgivable typo |
| 11:11 | <philipj> | annevk: would there be any benefit to delaying these callback ever so slightly? |
| 11:17 | <annevk> | philipj: "these"? |
| 11:18 | <philipj> | annevk: mutation events I mean |
| 11:18 | <annevk> | philipj: yes, all the code that deals with mutation events changing the world view would go away |
| 11:18 | <annevk> | philipj: and any undiscovered security bugs in those paths would go away too |
| 11:22 | <philipj> | annevk: well, that does sound nice, but mutation events have been annoying for a long time, is any browser willing to attempt the change? |
| 11:22 | <annevk> | philipj: it seems Blink is |
| 11:22 | <annevk> | philipj: see also https://github.com/whatwg/dom/issues/57 |
| 11:23 | <philipj> | perhaps I'm overestimating the amount of interop there currently is for these events |
| 11:24 | <annevk> | philipj: it seems Edge has a somewhat different model per that issue |
| 11:25 | <philipj> | Yeah... |
| 11:25 | <philipj> | Some details on that would be nice. |
| 11:26 | <philipj> | Like how would those invariants be enforced, what is it that causes a nested removeChild() call to fail, etc. |
| 11:26 | <annevk> | "https://bugzilla.mozilla.org/show_bug.cgi?id=559561 is pretty ugly |
| 11:27 | <philipj> | It would be interesting to know how common it is for mutation event listeners to actually mutate the DOM again |
| 11:28 | <philipj> | And if it isn't common at all, if there's a cheap check that could be done to simply disallow that. |
| 11:28 | <philipj> | That would make the problems go away I suppose. |
| 11:28 | <smaug____> | Gecko fires non-DOMNodeRemoved mutation events using script runners, so if nano task gets defined, and gecko makes a nano task to be a script blocker, non-DOMNodeRemoved would be fired a bit later in editor/selection case |
| 11:30 | <annevk> | and range case |
| 11:31 | <smaug____> | right |
| 11:31 | <annevk> | so we only run complicated code for DOMNodeRemoved at the moment? and for range operations? |
| 11:31 | <annevk> | hmm |
| 11:32 | <annevk> | I guess that's still less than if custom elements could run code in a bunch of these places |
| 11:32 | <annevk> | And I guess DOMNodeRemoved firing after is problematic because the tree is gone |
| 11:33 | <annevk> | You'd have to do something weird to notify parents |
| 11:34 | <smaug____> | sync custom element ctor case would add yet another new problematic case, cloneNode |
| 11:35 | <annevk> | smaug____: if you already need to code defensively for insertions and removals, is cloning making it much worse? |
| 11:36 | <smaug____> | perhaps not much. But it is yet another case |
| 11:37 | <smaug____> | maybe we'd be better with cloneNode than we were with other cases |
| 11:37 | <smaug____> | but would be nice to remove the sync stuff from everywhere |
| 11:37 | <smaug____> | that would simplify code |
| 11:37 | <smaug____> | ...but DOMNodeRemoved... |
| 11:38 | <annevk> | no disagreement there |
| 11:38 | smaug____ | kicks DOM WG around DOM 2 Events era ;) |
| 11:38 | <annevk> | I'm somewhat surprised they got away with just specifying these events without defining their processing model |
| 11:40 | <smaug____> | "processing model" in the web before 2004? |
| 11:42 | <annevk> | hah |
| 13:21 | <wanderview> | annevk: should <applet> be considered a potential client request? |
| 13:21 | <annevk> | wanderview: no |
| 13:22 | <annevk> | wanderview: though <applet> is underspecified |
| 13:22 | <wanderview> | annevk: should it be intercepted? (I guess I need to ask Matt what chrome does) |
| 13:22 | <annevk> | wanderview: it's unclear whether Java does the fetch or the browser and whether all Java fetches are browser-mediated |
| 13:22 | <annevk> | wanderview: there's one open bug against HTML on this, which blocks defining an "applet" context |
| 13:23 | <wanderview> | annevk: if we have no applet context, that implies to me we should not intercept... safe thing to do for now |
| 13:28 | <annevk> | wanderview: we should probably work through the <object> and <embed> cases some more too |
| 13:28 | <wanderview> | annevk: well, for now they are spec'd not to be intercepted |
| 13:28 | <wanderview> | which is at least not a security problem |
| 13:32 | <wanderview> | annevk: I guess its an interesting question for things like amazon.com... they have tons of <object> tags... would they have to rewrite their site to offline it? |
| 13:32 | <annevk> | wanderview: yeah |
| 13:32 | <annevk> | wanderview: the problem with <object> is that its both a client and resource context |
| 13:33 | <annevk> | wanderview: so you don't really know what service worker to use until after you got the response... |
| 13:33 | <annevk> | (if that sounds confusing, it's because it is) |
| 13:33 | <wanderview> | annevk: its ok... I put it in the bucket of "try to understand after we ship v1" for now |
| 13:33 | <annevk> | <applet> doesn't really have that problem, but I'm fine deferring all plugin-like stuff for a bit |
| 13:34 | <wanderview> | yea, makes sense |
| 13:34 | <annevk> | It does sound like Gecko at least manages some of the <applet> requests so I guess I should define a context for it |
| 13:34 | <annevk> | I wonder if anyone can confirm whether that's the case in Chrome too; beverloo maybe? |
| 13:35 | <annevk> | Perhaps mkwst is online? \o/ |
| 13:35 | <wanderview> | annevk: I asked Matt Falkenhagen (irc name?) |
| 13:35 | <annevk> | I think matto |
| 13:35 | <wanderview> | he said he would help dig up chrome's behavior for this stuff last week |
| 13:35 | <annevk> | or maybe his last name, not sure |
| 13:35 | <wanderview> | of course... timezones |
| 13:36 | <annevk> | in theory he's had his first work day, but maybe he took a day off, dunno |
| 13:36 | <mkwst> | Hi! Scrolling back, but the question isn't clear to me. What do you want to know about applet? |
| 13:37 | <annevk> | mkwst: basically whether Chrome or Java is in control of fetching |
| 13:37 | <wanderview> | well, I just sent him the email... he's probably just going to bed now :-) |
| 13:37 | <mkwst> | (other than that Sun doesn't seem to be publishing a PPAPI version of Java so maybe we can kill the tag entirely?) |
| 13:37 | <annevk> | aah |
| 13:37 | <wanderview> | mkwst: does chrome do any service worker interception for <applet> |
| 13:37 | <annevk> | (that'd be great) |
| 13:37 | <annevk> | well that's a different question, but I agree it would be good to know the answer to that one too |
| 13:38 | <mkwst> | We certainly trigger the request for the applet itself in Blink, and I suspect we have control over the whole request now that we've killed NPAPI. |
| 13:38 | <mkwst> | But, again, that's fairly theoretical, as I don't think there's any way of running Java in Chrome in Canary. Maybe even stable, I've lost track... |
| 13:39 | <mkwst> | For object and embed it's the same story, except insofar as Flash can open sockets. |
| 13:39 | <mkwst> | Sockets are outside Fetch, so it can do pretty much whatever it likes with the connection. |
| 13:39 | <annevk> | mkwst: https://java.com/en/download/faq/chrome.xml claims it is still available |
| 13:39 | <annevk> | mkwst: outside of Linux, anyway |
| 13:40 | <annevk> | Ooh, that actually tells people to switch the NPAPI flag... |
| 13:40 | <mkwst> | We might have killed the flag by now. |
| 13:40 | <wanderview> | well, object and embed are explicitly not sw intercepted per the current spec |
| 13:40 | <mkwst> | wanderview: Sure. I don't know off the top of my head whether the folks responsible for SW set the bypass flags when making requests. Give me a sec. |
| 13:41 | <annevk> | wanderview: you're saying that Gecko is also in control over the fetch for <applet>, right? |
| 13:41 | <wanderview> | annevk: I haven't looked, but this bug implies it does: https://bugzilla.mozilla.org/show_bug.cgi?id=1187766 |
| 13:41 | <annevk> | mkwst: https://github.com/whatwg/fetch/issues/73 is blocking on you |
| 13:42 | <annevk> | mkwst: https://github.com/whatwg/fetch/issues/52 too |
| 13:42 | <annevk> | mkwst: and https://github.com/whatwg/fetch/issues/45 |
| 13:43 | <wanderview> | annevk: you mentioned to me somewhere that sicking suggested redesigning context to better handle navigation/worker/client concepts... but you said it was too late... why is it too late? |
| 13:43 | <annevk> | wanderview: I figured since Chrome shipped we might not want to change context |
| 13:43 | <wanderview> | annevk: I don't think they implement .context yet |
| 13:43 | <wanderview> | just a sec |
| 13:43 | <annevk> | wanderview: sicking argued that we basically wanted a single context for everything that creates a browsing context |
| 13:43 | <annevk> | wanderview: and have a distinct flag for "comes from a form" that CSP can use |
| 13:44 | <wanderview> | annevk: they are just implementing it now: https://code.google.com/p/chromium/issues/detail?id=455116 |
| 13:44 | <annevk> | hmm okay |
| 13:45 | <wanderview> | annevk: not that I really want to rewrite a bunch of stuff... ehsan might be annoyed :-) |
| 13:45 | <wanderview> | but if its really better... we should consider it |
| 13:45 | <annevk> | wanderview: this would only be for all contexts that mean "navigation" |
| 13:46 | <annevk> | I guess I can investigate then, although I hope that doesn't cost too much time :/ |
| 13:46 | <wanderview> | ah, that sounds like less of a change |
| 13:47 | <wanderview> | annevk: if you have higher priority stuff... I don't think having the more granular values we do now is bad... just need this extra "is it a navigation" helper |
| 13:47 | <mkwst> | annevk: blocking on me is a seriously bad idea because I am overloaded and behind on everything. But I'll comment on the bugs anyway. :) |
| 13:47 | <annevk> | mkwst: is there a qualified fallback person? |
| 13:47 | <annevk> | mkwst: this is what you get with all those "small" specs :p |
| 13:47 | <wanderview> | mkwst: given that... if you are busy don't worry about the applet... I emailed mattto about it |
| 13:48 | <mkwst> | I think I'm abarth's qualified fallback person. |
| 13:48 | <annevk> | mkwst: we can't have abarth' go MIA too :p |
| 13:49 | <annevk> | maybe I should ask fishd about abarth'' |
| 13:49 | <wanderview> | annevk: should the SW spec be doing stuff like step 11 here? or should that be in fetch: http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#on-fetch-request-algorithm |
| 13:50 | <annevk> | wanderview: I think that's fine |
| 13:50 | <annevk> | wanderview: everything about picking a service worker is left up to SW |
| 13:50 | <wanderview> | ok |
| 13:51 | <wanderview> | seems security related which makes me think of those other checks in fetch |
| 13:52 | <annevk> | I think at some point we might need to figure out the layering again, but for now let's leave it like this |
| 13:52 | <annevk> | In general anything Fetch being part of service workers directly is somewhat dirty from a layering perspective |
| 13:53 | <wanderview> | annevk: well, looking at public attributes on Request should be ok |
| 13:53 | <wanderview> | its just annoying to spread security checks between specs where not necessary |
| 13:54 | wanderview | goes to fetch a baby. |
| 13:54 | <annevk> | wanderview: oh, I guess it should not look at the public properties |
| 13:55 | <annevk> | wanderview: that seems bad |
| 13:55 | <annevk> | wanderview: and I agree with that, but this is about deciding where to handle the fetch, it's not a decision on the response |
| 13:55 | <annevk> | wanderview: where to handle the fetch is not really a security decision per se |
| 13:58 | <annevk> | mkwst: ta |
| 14:00 | <mkwst> | annevk: I'm a seriously poor abarth`. At least, I have been this quarter, and August isn't looking any better. Hopefully the next one will be better. |
| 14:01 | <annevk> | mkwst: it's alright, the only thing that's making me nervous is wanderview alluding to us not shipping service workers due to CSP not being ready |
| 14:02 | <mkwst> | what, what? |
| 14:02 | <mkwst> | who would be crazy enough to do that? :) |
| 14:02 | <annevk> | I guess we'll have to wait for wanderview to confirm or deny |
| 14:04 | <mkwst> | Tell me what pieces of CSP are blocking SW, and I will make them go away. Unless it's "This doesn't make sense in terms of Fetch.", in which case, yes, I know, and ugh and I'm working on it. Slowly. |
| 14:06 | <JakeA> | annevk: going to go through https://github.com/whatwg/fetch/issues/79 while I've got a spare moment. Anything else that's particularly blocking? |
| 14:07 | <annevk> | JakeA: no not really |
| 14:08 | <annevk> | mkwst: well one issue we have is that it's unclear what the CSP check on responses will be and indeed whether the service worker can set CSP, etc. |
| 14:08 | <annevk> | mkwst: there's a great many unanswered questions, but perhaps I'm wrong about that blocking us shipping though |
| 14:08 | <annevk> | need to ask wanderview |
| 14:09 | <wanderview> | I'm back |
| 14:09 | <wanderview> | mkwst: annevk: I believe some form of CSP is a blocker for use service workers in firefoxos |
| 14:09 | <annevk> | JakeA: I mean, there's a great number of things I'd like to see resolved, such as range requests |
| 14:09 | <wanderview> | which means its a near time requirement for us |
| 14:10 | <wanderview> | mkwst: annevk: specifically... being able to say if src is constrained to a server... synthetic responses are not allowed... so you can't bypass the no-eval restrictions |
| 14:11 | <JakeA> | annevk: as in, how they appear in a fetch event, how a complete response may be handled, what the cache returns in response to a range, should the browser accept range parts from different sources? |
| 14:12 | <annevk> | JakeA: yeah, those type of questions |
| 14:12 | <annevk> | JakeA: media elements already make them, so I guess to some extent browsers handle them already |
| 14:13 | <JakeA> | yeah, and it feels like having a cache able to produce partial results would be the most compatible and performant way to deal with those |
| 14:14 | <annevk> | makes sense |
| 14:17 | <wanderview> | I wonder if this overlaps with returning partial responses that are still streaming in for cache.match() of "fetching entry" |
| 14:21 | <JakeA> | wanderview: not sure… we wouldn't want to return an http partial response in response to a non-range request |
| 14:22 | <JakeA> | I think that'd be a failure case |
| 14:22 | <JakeA> | although we might have some magic the other way around |
| 14:22 | <wanderview> | JakeA: I guess the question becomes... do partial responses become a combined complete response when all the pieces are cached? |
| 14:23 | <JakeA> | if the request is a range, and I respond with new Response("hello world"), should SW or Fetch attempt to create an appropriate partial response (I think it should) |
| 14:24 | <JakeA> | wanderview: ohh I see. Yeah, that seems really difficult. We could reject in that case |
| 14:24 | <wanderview> | oh... so Cache stores the whole thing... but might slice it given a range request? |
| 14:24 | <JakeA> | yeah, that's what I was thinking |
| 14:24 | <wanderview> | that seems reasonable |
| 14:24 | JakeA | ponders |
| 14:25 | <wanderview> | JakeA: I guess I'm trying to understand what to do in a read-through-cache scenario where a partial request comes... what gets stored in the cache |
| 14:25 | <JakeA> | yeah, I'm thinking the same |
| 14:25 | <wanderview> | aren't you on PTO? |
| 14:26 | <JakeA> | yeah but all my friends are asleep so I'm stuck with you guys |
| 14:26 | <JakeA> | :D |
| 14:26 | <wanderview> | ha |
| 14:27 | <JakeA> | so, cache.put(videoRequest.url, fetch(videoRequest.url)).then(r => {) |
| 14:27 | <JakeA> | shit |
| 14:27 | <JakeA> | hit enter too soon |
| 14:28 | <JakeA> | cache.put(videoRequest.url, fetch(videoRequest.url)).then(_ => cache.get(videoRequest)) |
| 14:28 | <wanderview> | JakeA: do range requests become less important once we get real streams? |
| 14:29 | <wanderview> | because that snippet of code seems reasonable in a Stream API world |
| 14:29 | <wanderview> | (if requiring some work to implement) |
| 14:30 | <JakeA> | The above would work if the user watched the video sequentially. But if they scrubbed, they'd be waiting for the sequential download to catch up, which isn't great. |
| 14:30 | <wanderview> | right, ok |
| 14:30 | <JakeA> | wanderview: with streams, wouldn't there be a lot of code effort to turn those into range responses? |
| 14:30 | <JakeA> | I guess the question is whether the cache should be that high level |
| 14:31 | <JakeA> | (I'm thinking it should) |
| 14:31 | <wanderview> | maybe we should just look at what http cache offers |
| 14:32 | <wanderview> | if it just treats ranges as any other request |
| 14:32 | <wanderview> | or if it does magic |
| 14:34 | <annevk> | note that for at least some media, we seek to the last set of bytes |
| 14:35 | <annevk> | some containers are broken like that |
| 14:35 | <annevk> | ideally we cleanly handle all those scenarios |
| 14:35 | <wanderview> | section 13.5.4 here suggests that combining is allowed per the spec... who knows if anyone implements it: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html |
| 14:36 | <annevk> | and streams doesn't solve seek and such |
| 14:36 | <wanderview> | http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.5.4 |
| 14:36 | <annevk> | I think we're stuck with both |
| 14:38 | <wanderview> | JakeA: I think I might just make the Cache API matching algorithm include range comparisons so they are unique... and then offer a .merge(reqList) to combine them if the client code wants |
| 14:38 | <wanderview> | so read-through-caching works |
| 14:38 | <wanderview> | if they want to optimize and merge they can |
| 14:38 | <wanderview> | and then do your auto-slicing thing on match |
| 14:39 | <annevk> | can't we auto-merge them? |
| 14:40 | <wanderview> | annevk: it seems to me we try to let script control how the Cache works instead of being magical like http cache |
| 14:40 | <wanderview> | so I'd rather give them an API to do it if they want |
| 14:40 | <annevk> | wanderview: hmm, the Cache API is fairly high-level |
| 14:40 | <annevk> | wanderview: e.g. the whole match algorithm |
| 14:40 | <annevk> | for starters |
| 14:40 | <wanderview> | annevk: but we explicitly don't do any *modification* of the cache automatically... its all script controlled |
| 14:41 | <annevk> | I guess, but it does seem fairly silly if range requests/responses require a bunch of make work whereas everything else just works |
| 14:42 | <wanderview> | annevk: the rfc suggests you don't always want to merge... if one part of the range is newer than the rest, etc |
| 14:43 | <wanderview> | anyway... happy to let Jake figure this out while his friends are asleep :-) |
| 14:43 | <annevk> | I mean, in that case it says you must discard the older bits |
| 14:43 | <annevk> | If they're not equivalent cache-wise |
| 14:44 | <wanderview> | annevk: and we explicitly don't discard things automatically in Cache API... |
| 14:44 | <wanderview> | the whole point of the API was to let the script decide |
| 14:45 | <annevk> | fair, but sounds fairly complicated to combine that with ranges |
| 14:45 | <annevk> | and keep the API convenient |
| 14:46 | <wanderview> | they can .match() all the ranges, manually combine into a new Response, and then Cache put it back... the .merge() was a convenience to do that efficiently in the platform |
| 14:47 | <annevk> | you're assuming ranges are non-overlapping |
| 14:48 | <wanderview> | am I? it would be a pain, but script could do it with current primitives |
| 14:48 | <annevk> | or maybe you're saying I need to make a side-table to store all the ranges |
| 14:49 | <annevk> | it's not entirely clear to me how to get ranges out of the cache if all I have is a URL |
| 14:50 | <wanderview> | oh... well that would need to be added, yea... I thought we were talking about a world where you could pass range requests to .match() |
| 14:51 | <wanderview> | anyway, if it can be done automatically without losing data then thats cool with me |
| 14:53 | <JakeA> | I'm kinda happy with cache being high level, hopefully idb will become the place to do it if you need lower level |
| 14:54 | <JakeA> | but I need to think about it more |
| 14:56 | <wanderview> | annevk: why do we even have CORS responses if they can be so easily converted to synthetic responses? should we just have one type? |
| 14:57 | <annevk> | wanderview: https://fetch.spec.whatwg.org/#concept-filtered-response-cors |
| 14:57 | <wanderview> | prevents copying the headers I guess |
| 14:57 | <annevk> | if you ignore some set of data, everything is the same type |
| 14:58 | <annevk> | that's how you end up with == and security bugs |
| 14:59 | <wanderview> | yea, I forgot about the headers... seems we spend all our time worrying about cross-origin body content |
| 15:00 | <annevk> | that's also what leads people to think ReadableStream is all we need |
| 15:00 | <annevk> | might even be the same people |
| 15:00 | <annevk> | :-P |
| 15:01 | <annevk> | (I didn't follow that navigation attack scenario from JakeA btw, seems wrong?) |
| 15:03 | <JakeA> | annevk: Am I right in thinking the attack is exposed when a client request is made to the "infected" url? |
| 15:04 | <JakeA> | that's when the cross-origin code is executing |
| 15:05 | <JakeA> | The bad stuff goes into the cache via a cors request, and comes back out via a client request - that was my understanding, but I haven't seen the attack work (in a while) so I'm not sure |
| 15:07 | <annevk> | JakeA: oh wait, the Cache API would follow redirects whereas navigation doesn't? |
| 15:07 | <annevk> | JakeA: yeah, I think the Cache API is somewhat broken here, in storing the redirected response but still with the original request URL... |
| 15:08 | <JakeA> | annevk: the cache would end up with an entry where the key was "good site" and the value was "bad site". Then when the navigation happens, the "bad site" entry is pulled out |
| 15:08 | <JakeA> | I mean, they can both be synthetic |
| 15:08 | <annevk> | JakeA: yeah, understood |
| 15:09 | <wanderview> | Cache API should store the final URL property on the Response, no? |
| 15:09 | <JakeA> | yeah |
| 15:09 | <annevk> | JakeA: that seems like a problem with usage of the Cache API |
| 15:09 | <annevk> | JakeA: or design of the Cache API... |
| 15:10 | <annevk> | JakeA: it should be some kind of explicit action to persist a redirect in the cache |
| 15:10 | <JakeA> | I mean, if we're nervous about it, we could consider rejecting if the request/response have different origins. You could still do it with synthetics though |
| 15:10 | <annevk> | A synthetic is explicit |
| 15:10 | <annevk> | Different origins seems ugly |
| 15:10 | <annevk> | And doesn't work for same-origin -> cross-origin -> same-origin |
| 15:11 | <wanderview> | this would be a breaking change, no? |
| 15:11 | <annevk> | Yes |
| 15:12 | <wanderview> | annevk: what about fetch(redirectingURL).then(function(response) { cache.put(sameOriginURL, response) }); ? |
| 15:12 | <annevk> | wanderview: that's fairly explicit too |
| 15:12 | <wanderview> | where the fetch is done external to Cache |
| 15:12 | <annevk> | wanderview: we don't even change contexts in that case |
| 15:12 | <wanderview> | annevk: so you just want to block redirects in cache.add()? |
| 15:13 | <annevk> | wanderview: dunno |
| 15:14 | <annevk> | But I don't really think the design of the cache should result in further restrictions in Fetch |
| 15:14 | <annevk> | that seems quite backwards |
| 15:15 | <annevk> | and not actually solving the problem |
| 15:15 | <annevk> | which will popup elsewhere if left unsolved |
| 15:16 | <wanderview> | annevk: why does this need Cache API? can't the service worker just do a fetch(url, {mode: 'cors'}) and respondWith immediately? |
| 15:16 | <wanderview> | unclear to me why Cache is relevant here |
| 15:17 | <wanderview> | JakeA: why do you need Cache for this? it seems a standalone fetch() could result in "bad stuff"... which is then returned for a client request |
| 15:18 | <JakeA> | wanderview: yeah, but it's the cache that may be making it easier for this to happen by accident |
| 15:18 | <JakeA> | right, I'm heading out, just as it was getting interesting. Sorry! |
| 15:19 | <wanderview> | JakeA: I guess I was asking in reference to annevk's "I don't really think the design of the cache should result in further restrictions in Fetch" |
| 16:07 | <JonathanNeal> | I’m writing about @font-face and type foundries, but I’m having trouble distinguishing between a distributor like “The League of Movable Type” and “Google Fonts”. Both fulfill the definition, but one doesn’t really produce their own fonts. What do I call something like Google Fonts or TypeKit? |
| 16:17 | <wanderview> | JakeA: annevk: our http cache behavior for range requests: https://pastebin.mozilla.org/8840726 |
| 16:44 | <annevk> | JonathanNeal: why not just say that some are X, some are Y, some are both? |
| 16:44 | <JonathanNeal> | annevk: I haven’t found anywhere that really does both. |
| 16:45 | <annevk> | wanderview: whoa, if you do a range request and you get a 200 we refetch? |
| 16:45 | <annevk> | wanderview: I guess that's one case that's not currently considered |
| 16:45 | <annevk> | JonathanNeal: so font foundry vs CDN? |
| 16:46 | <JonathanNeal> | What I’ve learned (or so I think I’ve learned) is that Google Fonts and TypeKit are “typeface directories”. |
| 16:46 | <annevk> | I don't think there's any authority on the terms for those things |
| 16:46 | <annevk> | I guess you could look at Wikipedia |
| 16:47 | <JonathanNeal> | Yeap, Wikipedia and Googling for some kind of blog consensus. TypeKit never refers to themselves as such, since they describe themselves for their service and not their collection. |
| 16:47 | <annevk> | wanderview: also, that seems like an oversimplification, unless we really don't do any validation of the various ranges we have in the cache |
| 16:48 | <JonathanNeal> | annevk: and “directory” is a tricky name, since I think of a typeface directory as the place I put my self hosted fonts for a relative path @font-face rule. |
| 16:48 | <wanderview> | annevk: it probably is a simplification... but I don't think its surprising that implementations do something simpler that might be faster and less complex to implement |
| 16:59 | <annevk> | JonathanNeal: I would just go with font CDN and font foundry personally |
| 16:59 | <annevk> | wanderview: or just do something weird :-) |
| 17:01 | <JonathanNeal> | annevk: I’ll consider that, yea. I now appreciate how brew abstracted the whole thing to “taps”. |
| 17:17 | <wanderview> | annevk: you can always go ask mayhemer to clarify in #necko |
| 17:17 | <annevk> | wanderview: I take it you're no longer in #necko :-) |
| 17:18 | <wanderview> | annevk: I am... but I don't look at it often... I see you're harassing him now |
| 17:19 | <annevk> | wanderview: do you have useful copy-and-paste for IRC? |
| 17:19 | <wanderview> | annevk: I just copy to pastebin I guess |
| 17:19 | <annevk> | wanderview: would love to have everything from your question down into https://github.com/whatwg/fetch/issues/38 somehow |
| 17:19 | <wanderview> | annevk: I'll copy it |
| 17:20 | <annevk> | wanderview: but whenever I copy-and-paste the formatting around the nickname goes all bonkers |
| 17:20 | <annevk> | ta |
| 17:20 | <wanderview> | I think irccloud works ok for this |
| 17:20 | <annevk> | LimeChat-- |
| 17:21 | <wanderview> | done |
| 17:21 | <wanderview> | annevk: mozilla instance of irccloud works pretty well |
| 17:21 | <annevk> | Yeah, I guess I should switch, mostly been putting it off due to inertia |
| 17:23 | <wanderview> | annevk: hmm... it did lose the names on the log when I pasted it |
| 17:23 | <wanderview> | I'll fix it |
| 17:27 | <wanderview> | annevk: I guess irccloud messed up too... put names in brackets like <bkelly>... which markdown just treats as html and hides |
| 17:27 | <annevk> | wanderview: use ``` and ``` around it? |
| 17:27 | <annevk> | wanderview: GitHub might even support ```irc for IRC highlighting... |
| 17:28 | <wanderview> | annevk: I already modified it to show in markdown |
| 17:28 | <annevk> | ait |
| 17:29 | <wanderview> | annevk: what does "ait" mean? |
| 17:29 | <annevk> | alright |
| 17:30 | <wanderview> | ait |
| 17:30 | <annevk> | k |
| 17:37 | <wanderview> | annevk: if there is a defined RequestContext enum value in fetch... does that mean it should be intercepted? or just that you think it might be reasonable to intercept if someone wants to spec it? |
| 17:39 | <annevk> | wanderview: in principle I think everything should be intercepted |
| 17:40 | <wanderview> | annevk: I feel I can usefully take this statement out of context... thanks |
| 17:45 | <annevk> | hah |
| 17:52 | hallvors | wants to joke about annevk and the NSA |
| 17:54 | <hallvors> | annevk: joking aside, on to spec editing style questions |
| 17:54 | <annevk> | evening hallvors |
| 17:54 | <hallvors> | I like having a prose description of what we're up to |
| 17:55 | <annevk> | hallvors: so one problem with the before* not being integrated is that it's not very clear when they fire in relation to the other events |
| 17:55 | <annevk> | hallvors: and whether they fire from different tasks or not |
| 17:55 | <hallvors> | aha |
| 17:55 | <annevk> | hallvors: and what happens if you launch a copy operation from one of them |
| 17:55 | <annevk> | hallvors: etc. |
| 17:56 | <hallvors> | there is a "processing model" section for them, but *when* they fire is not spec'ed |
| 17:56 | <hallvors> | https://w3c.github.io/clipboard-apis/#processing-model-for-before-events |
| 17:56 | <annevk> | hallvors: if you don't have a very clear set of steps, it's super easy to poke holes |
| 17:57 | <annevk> | hallvors: so those fiddle with a command state in the end, which requires more than just firing an event |
| 17:57 | <annevk> | hallvors: they require execution of some command |
| 17:57 | <hallvors> | exactly when to fire them is left up to the implementation.. they aren't really about commands, they are about UI |
| 17:57 | <annevk> | hallvors: currently you'd get a nullpointer exception |
| 17:58 | <annevk> | hallvors: well presumably they fire in response to some action by the user, from a task |
| 17:58 | <hallvors> | I may need a better word than "command".. |
| 17:59 | <hallvors> | it's up to the UA when to fire them, but typically it would happen for example when the user opens the "Edit" menu |
| 17:59 | <annevk> | ah right, they're unrelated to firing of the non-before events |
| 18:00 | <hallvors> | so the UA is about to show the user a menu containing "copy"/"cut"/"paste" commands, and wants to enable or disable them |
| 18:00 | <hallvors> | exactly. They are sort of completely unrelated to those other clipboard events.. |
| 18:00 | <annevk> | so what you actually want to define then is a set of steps for displaying "edit UI" |
| 18:00 | <annevk> | And then you have an algorithm whenever you "display edit UI" |
| 18:01 | <annevk> | To figure out how you display it |
| 18:01 | <annevk> | It happens to run some script from a queued task to figure that out |
| 18:01 | <annevk> | Do you get distinct tasks for each event? Or do they share a task? |
| 18:01 | <annevk> | That's the kind of thing that should be obvious from that algorithm |
| 18:01 | <hallvors> | right |
| 18:02 | hallvors | will report a github issue on the spec |
| 18:02 | <hallvors> | spent way too much time on this today already due to git doing things I didn't understand.. |
| 18:02 | <annevk> | ah sorry :-( |
| 18:03 | <annevk> | tooling issues are the worst |
| 18:03 | <hallvors> | well, it's not your fault :) |
| 18:03 | <hallvors> | I assume :) |
| 18:03 | <annevk> | I guess sympathize is a better word |
| 18:04 | <hallvors> | thanks! appreciated. I got into some weird state where a submodule was there but wasn't there. somehow. |
| 18:04 | <hallvors> | #-] |
| 18:04 | <annevk> | I usually lazy-IRC for all git issues I encounter |
| 18:04 | <annevk> | There's a surprising number of people on #whatwg who know what's what |
| 18:05 | <hallvors> | well, MikeSmith helped me out in irc.w3's#testing |
| 18:09 | <annevk> | back later, time for a break |
| 18:56 | <ccardona-work> | o/ whatwg |
| 18:58 | <wanderview> | writing this blog post is triggering all my worst procrastination tendencies from school |
| 19:10 | <JonathanNeal> | Is there a name for the css pattern seen as url(), local(), and format() ? |
| 19:10 | <Ms2ger> | Function? |
| 19:36 | <TabAtkins> | annevk: Something like "In parallel with the rest of the algorithm, run the following steps:" would work. As it's written, the "in parallel" part is implied to apply over the "following steps" not over the rest of the algorithm as it should be. |
| 19:37 | <TabAtkins> | JonathanNeal: Yes, function. Or functional notation, either works. |
| 19:38 | <JonathanNeal> | Thank you, Ms2ger, TabAtkins. :) |
| 21:32 | <annevk> | TabAtkins: shrug, file bugs? |