| 06:32 | <annevk> | jgraham: parse it and see if the serialized result is the same as the input |
| 06:32 | <annevk> | jamesr___: ah, but what it's called? |
| 06:43 | <karlcow> | https://bugzilla.mozilla.org/show_bug.cgi?id=1137079 |
| 06:43 | <karlcow> | Bug 1137079 - https://whatwg.org/ Secure Connection Failed (Error code: ssl_error_no_cypher_overlap) |
| 07:25 | <annevk> | karlcow: can you reproduce it? |
| 07:31 | karlcow | is switching to Firefox 39.0a1 (2015-02-25) |
| 07:31 | karlcow | is going to https://bugzilla.mozilla.org/show_bug.cgi?id=1137079 |
| 07:33 | <karlcow> | failing on https://forums.whatwg.org/ |
| 07:34 | <annevk> | karlcow: yeah, multiple subdomains are not on the whitelist, I left a comment on the whitelist bug emk pointed out |
| 07:34 | karlcow | sees https://hg.mozilla.org/releases/mozilla-aurora/file/2e3aaa26bca4/security/manager/ssl/src/IntolerantFallbackList.inc |
| 07:34 | <annevk> | karlcow: euh, emk did point that out, someone else did |
| 07:34 | <annevk> | karlcow: e.g. images.w.o spec.w.o validator.w.o all fail too |
| 07:35 | <karlcow> | ah yes. |
| 07:35 | <karlcow> | https://bugzilla.mozilla.org/show_bug.cgi?id=1137079#c6 |
| 07:35 | karlcow | hopes the whitelist is serverside and not included in the client. |
| 07:37 | <annevk> | karlcow: it's included in the client |
| 07:37 | <annevk> | karlcow: not sure why it matters |
| 07:40 | <karlcow> | annevk: for updates. |
| 07:40 | <karlcow> | When it's included in the client you create a delay |
| 07:41 | <karlcow> | it's becoming an acute issue when it's on Mobile. |
| 07:41 | <karlcow> | because not all operators decide to update the OS. |
| 07:41 | <karlcow> | (for FIrefox OS) |
| 07:41 | <karlcow> | so you keep having a whitelist which is not accurate anymore. |
| 07:41 | <karlcow> | And domains get bought by other people, etc. |
| 07:42 | <karlcow> | We had the issue for UA override on Firefox OS 1.0. |
| 07:43 | <karlcow> | So we decided to switch to server-side for the next version. |
| 07:44 | <karlcow> | So we could remove (or add) at will a UA override without having to wait for the operator to cherry pick the update, or waiting that it will never update. :) |
| 07:48 | <annevk> | That depends on what the update logic is. If operators decide to remove the update logic... |
| 08:35 | <JakeA> | wanderview: yeah, kill it |
| 08:53 | <JakeA> | wanderview: I've removed it from the spec. I forgot it was still there. I think there are uses, but we'll properly think it through before adding it back |
| 09:08 | <zcorpan> | Hixie: looks like there are a few markup errors in your source that darobin fixed in https://github.com/w3c/spork/commits/master (like x-data) |
| 09:39 | <JakeA> | "Release the storage mutex!" is my favourite thing to shout in an evil voice |
| 10:07 | <annevk> | JakeA: why is default() still in the spec? |
| 10:08 | <annevk> | JakeA: also, nobody implements the storage mutex :-( |
| 10:08 | <JakeA> | annevk: I'm working through issues now. Will get to that one :) |
| 10:08 | <annevk> | JakeA++ |
| 10:09 | <annevk> | (I like to think that gives you extra speed.) |
| 10:12 | <JakeA> | :D |
| 11:58 | <JakeA> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/631#issuecomment-75740946 are you saying the client may have gone before the beacon initiates its request? |
| 12:15 | <JakeA> | annevk: So, without event.default(), how would I fetch a resource (say, CSS) in a way that makes relative urls in the CSS relative to finalURL |
| 12:15 | <JakeA> | ? |
| 13:33 | <annevk> | JakeA: yes, the client may have gone |
| 13:34 | <annevk> | JakeA: ping="" and such are required to be done at some point, but usually after the user has navigated away, the whole point is that they're a replacement for synchronous beforeunload tricks |
| 13:34 | <annevk> | JakeA: might still not be a problem I suppose, depends a bit on the definitions |
| 13:34 | <JakeA> | annevk: that's a good case for it being clientless, or perhaps even not using the SW at all |
| 13:34 | <annevk> | JakeA: I think it should use the SW just like it should be subject to CSP, we don't really want special cases |
| 13:35 | <JakeA> | that's fair, as long as they don't hold up a waiting SW promoting to active |
| 13:35 | <annevk> | JakeA: people are going to want to be able to catch all networking activity |
| 13:35 | <JakeA> | but I think that's fine |
| 13:35 | <annevk> | JakeA: https://fetch.spec.whatwg.org/#dom-response-finalurl was the answer we designed together for base URLs |
| 13:37 | <JakeA> | annevk: if I use fetch('/static/fallback.html') as a response to a navigation, does it effect base urls or the url bar? |
| 13:39 | <annevk> | JakeA: not unless you set finalURL |
| 13:40 | <annevk> | JakeA: I'm not sure we fully considered the case of contexts that set the manual redirect flag though... Hmm |
| 13:40 | <JakeA> | annevk: ahhh ok, so it's not automatically set. So fetch('/blah.css') will swallow redirects by default, if I want the base url to reflect that I have to set finalURL manually (but, I can't observe the redirects) |
| 13:41 | <annevk> | JakeA: yes |
| 13:42 | <annevk> | JakeA: for navigation and other contexts that don't follow redirects finalURL should probably be either be ignored or be cause for a network error or a really special synthetic redirect that I'm sure of how it would work |
| 13:43 | <JakeA> | ignore seems good |
| 13:43 | <JakeA> | annevk: So if I wanted to fetch(someCSS) & have potential redirects reflected in the base url, is there a way to do that? |
| 13:46 | <annevk> | JakeA: yeah, but it's cumbersome I see now |
| 13:46 | <annevk> | JakeA: once you get hold of res, you'd do res.finalURL = true |
| 13:46 | <JakeA> | ohhhhhhhhh, it's a boolean! |
| 13:46 | <JakeA> | That was the missing bit |
| 13:46 | <JakeA> | nah, that's not cumbersome that's fine |
| 13:46 | <annevk> | JakeA: but it seems like you want something like fetch(someCSS, {finalURL:true }) maybe... hmm |
| 13:47 | <annevk> | ok |
| 13:47 | <annevk> | It feels a bit better to expose it only on response |
| 13:47 | <JakeA> | fetch(url).then(r => r.finalURL = true && r) |
| 13:47 | <JakeA> | fetch(url).then(r => (r.finalURL = true) && r) |
| 13:49 | <JakeA> | annevk: Willing to bikeshed on the name? I totally assumed finalURL would be a string url |
| 13:51 | <annevk> | JakeA: yeah, though I would prefer a ticket someplace then |
| 13:55 | <JakeA> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/607#issuecomment-76181254 |
| 13:57 | <annevk> | JakeA: yeah that seems good, and yeah, it's supposed to be stored as part of transfering the response |
| 13:58 | <annevk> | JakeA: otherwise it wouldn't make it into the Fetch process either |
| 14:02 | <annevk> | "Intent to Remove showModalDialog" exciting day |
| 14:18 | <annevk> | JakeA: renamed finalURL btw |
| 14:18 | <JakeA> | \o/ |
| 14:18 | <JakeA> | Lemmie remove event.default() |
| 14:18 | <JakeA> | I'm going to enjoy this |
| 14:36 | <r4vi> | is there any proposals for a 'force incognito' API |
| 14:36 | <r4vi> | for sites that say domestic abuse victims |
| 14:36 | <r4vi> | or something would use |
| 14:42 | <JakeA> | It'd be nice if a browser could take a tab incognito. Undoing history should be ok, tougher to deal with cookie/idb/ls changes |
| 14:43 | <zcorpan> | JakeA: try opera 12 |
| 14:43 | <JakeA> | zcorpan: did it do that? |
| 14:43 | <JakeA> | those guys thought of everything |
| 14:43 | <zcorpan> | yes |
| 14:44 | <jgraham> | "Opera did it first" |
| 14:44 | <zcorpan> | well you could open a new private tab, you couldn't make an existing tab private |
| 14:45 | <JakeA> | oh, I meant taking an existing tab private |
| 14:45 | <JakeA> | *everyone* can open private tabs |
| 14:45 | <zcorpan> | um... how? |
| 14:46 | <JakeA> | incognito… or are you going to be pedantic and say that's a new window not tab? :P |
| 14:46 | <zcorpan> | yes? of course a window is not a tab :-) |
| 14:46 | <JakeA> | *fert* |
| 14:47 | <JakeA> | that's a fart sound for your pedantry |
| 14:48 | <zcorpan> | ah ok, i never knew it was pedantry that came out of my ass :-D |
| 14:49 | <JakeA> | But the idea of a forcing incognito is interesting. It'd need to be done as a header. I imagine banks would all do it for "security" reasons, so the user would need a way to opt out, and if that opt out is "remembered" you kinda lose the original use-case |
| 14:49 | <zcorpan> | so going back, what would you expect to happen when you make an existing tab private? |
| 14:50 | <JakeA> | zcorpan: it to "undo" any non-private stuff it did, and reload in private mode. I realise the undo part is not really possible |
| 14:51 | <JakeA> | r4vi: is this just a sudden idea or is a group lobbying for this? |
| 14:53 | <r4vi> | JakeA: I'm actually working on a site that would find this useful |
| 14:53 | <r4vi> | so sudden idea |
| 14:53 | <jgraham> | It should be noted that it doesn't offer any "meaningful" security e.g. someone could set up the router to log all outbound DNS |
| 14:53 | <JakeA> | that's true. Could even be false security. |
| 14:53 | <jgraham> | Of course the population of people who would do that is smaller than the population of people that can look through browser history |
| 14:54 | <r4vi> | JakeA: we're currently linking them to this guide http://www.youandco.org.uk/node/240 |
| 14:54 | <r4vi> | but wish there was a more user-friendly way |
| 17:19 | <Ms2ger> | :( https://bugzilla.mozilla.org/show_bug.cgi?id=1107378 |
| 17:29 | <jgraham> | Not that surprising |
| 18:09 | <Ms2ger> | So who supports before/afterscriptexecute now? Gecko/Servo/Presto? |
| 18:27 | <wanderview> | JakeA: if a ServiceWorker script does "new Worker('nested_worker.js')"... is that something we support? should the nested worker script be automatically cached like importScript()? |
| 19:11 | <JakeA> | wanderview: I don't see why we wouldn't support it, but I don't think it should be importScript cached. |
| 19:11 | <JakeA> | But it wouldn't be a lot of use |
| 19:12 | <JakeA> | But if devs find a use for it, they can store the script text in idb or a cache |
| 19:28 | <wanderview> | JakeA: I think we're going to disallow it for now in gecko... another problem is life cycle... if the SW gets killed at any time... it should stop the dedicated worker... (right?) seems like it will be very difficult to use |
| 19:28 | <wanderview> | JakeA: if they store the script text manually... then they are using a data URI worker, right? |
| 19:29 | <wanderview> | it was my impressions blink didn't support nested workers at all yet, anyway... so this may just be a gecko thing |
| 19:41 | <JakeA> | wanderview: yeah, and yeah it'll get killed when the SW does. I can't think of many use cases for wanting a dedicated worker in a SW. |
| 19:41 | <wanderview> | JakeA: the nested SharedWorker, though... that could be useful |
| 19:42 | <JakeA> | wanderview: an interesting question I guess is whether the request for the worker/sharedworker goes through the SW |
| 19:43 | <wanderview> | JakeA: if it originates from a ServiceWorker, I thought the skip serviceworker flag was set |
| 19:46 | <wanderview> | JakeA: so if the sharedworker was first created from the document... then intercepted by SW... if first created from SW, then no interception... so dead simple for devs! |
| 19:46 | <wanderview> | ^so dead simple^sounds dead simple |
| 19:46 | <wanderview> | of course no one supports this case currently as far I know |
| 19:46 | <wanderview> | we only expose SharedWorker on the main thread |
| 20:36 | <Ms2ger> | longdesc is a rec |
| 20:36 | <Ms2ger> | Good job everyone |
| 20:37 | <Ms2ger> | Can we now finally go back to something useful? |
| 20:44 | <smaug____> | like reviewing perf wg's specs? Sounds like a good idea |
| 20:44 | smaug____ | hears Ms2ger just volunteered |
| 20:45 | <Ms2ger> | I was thinking more shutting them down on the next rechartering |
| 20:45 | <jamesr___> | sgtm |
| 20:45 | <jamesr___> | like most things in w3c it was created to work around other badness in w3c process |
| 20:46 | <jamesr___> | now that all vendors have official joined the WG there's no point in having it be separate |
| 20:46 | <jamesr___> | (before they joined there was the possibility of moving things through that WG faster than others like public-webapps due to membership differences) |
| 20:46 | <smaug____> | (perf wg's issues aren't w3c process issues) |
| 20:47 | smaug____ | goes back to reviewing |
| 20:47 | <Ms2ger> | Perf wg is more "eh, whatever" |
| 20:47 | <Ms2ger> | "You got comments? Ain't nobody got time for that!" |
| 20:55 | <TabAtkins> | Ms2ger: "But we can measure exactly how much time ain't nobody got!" |
| 20:58 | <miketaylr> | can't wait for longdesc2 |
| 21:21 | <jamesr___> | smaug____: i'm just talking about why it was created and used, not how it functions in practice |
| 21:21 | <jamesr___> | i agree it's pretty terrible |
| 21:30 | <smaug____> | ah, I don't even recall why it was created (and why the specs aren't written in webapps wg) |
| 21:45 | <jamesr___> | concerns about charter or velocity or both in the webapps wg |
| 21:46 | <jamesr___> | in w3c if you make a new wg you get to pick the members and charter and you can pick a set of members that will agree to the charter you want |
| 21:46 | <jamesr___> | whereas to spec a new thing in an existing WG you have to make sure it's within charter and if not get all existing members of the WG to agree to that charter |
| 21:46 | <Ms2ger> | In whatwg, you can write a spec :) |
| 21:51 | <caitp-> | who is going to stop you from writing a spec |
| 21:52 | <caitp-> | the tzar of the internet? |
| 22:12 | <jamesr___> | if you want to publish it as a w3c spec (which some people find important, not that i find all that much value in that personally) then the w3c will |
| 22:13 | <Ms2ger> | Sure, every monkey can get a spec published at w3c |
| 22:13 | <Ms2ger> | Case in point: me |
| 22:14 | <TabAtkins> | Ms2ger: Wait, which spec did you write? |
| 22:15 | <Ms2ger> | DOM |
| 22:15 | <Ms2ger> | Under various names |
| 22:15 | <wanderview> | jsbell: hi! do you know about how blink offlines the ServiceWorker script itself and its importScript() scripts? |
| 22:16 | <wanderview> | jsbell: just curious how blink handles a delayed importScript() call... like if the script does setTimeout(function() { importScript('annoying.js'); }, 5000) |
| 22:17 | <wanderview> | I guess we just don't guarantee that any delayed script loads will be cached? |
| 22:17 | <wanderview> | just makes it difficult to ensure we have a coherent set of scripts cached for offline use |
| 22:17 | <TabAtkins> | wanderview: ServiceWorkers that last too long just get killed; nothing gets preserved across. |
| 22:18 | <TabAtkins> | If you want to cache scripts with better guarantees, do a standard fetch and put it in a cache, then import it. |
| 22:19 | <wanderview> | TabAtkins: with importScript(datauri) or something? I wasn't clear how someone could take a fetch Response and get it into importScript() |
| 22:19 | <TabAtkins> | Given the current API, yeah, a data: url. |
| 22:21 | <wanderview> | TabAtkins: so you think this is a dev evangelism issue? people should just use importScripts() synchronously with the top line SW script or not at all? |
| 22:21 | <TabAtkins> | I suspect so, yeah. |
| 22:21 | <TabAtkins> | Standard SW wisdom: don't count on anything sticking around, you'll be disappointed eventually. |
| 22:22 | <wanderview> | TabAtkins: yea... I know... but as an implementer, I'd like to be able to say "we've successfully offlined this SW and its dependent scripts"... but basically we can't ever know when its done |
| 22:22 | <TabAtkins> | Well, yeah, you have no idea when a SW is going to request more things off the network. |
| 22:24 | <wanderview> | I guess thats why this is still open: https://github.com/slightlyoff/ServiceWorker/issues/106 |
| 22:25 | <slightlyoff> | hrm, I'm not sure that still needs to be open |
| 22:26 | <slightlyoff> | TabAtkins: also, that's pretty BS |
| 22:26 | <Ms2ger> | Bikeshed? |
| 22:26 | <TabAtkins> | slightlyoff: ? |
| 22:26 | <slightlyoff> | TabAtkins: "requesting more things off the network" post-install-setup phase means you didn't really want 'em |
| 22:26 | <slightlyoff> | TabAtkins: if you liked it, you should have put a top-level importScripts() on it |
| 22:27 | <TabAtkins> | Um, okay. I mean, sure, it's obviously not a *strict dependency*, but I fail to see the relevance. |
| 22:27 | <wanderview> | slightlyoff: its unclear to me from #106 what the end result of this was... |
| 22:28 | <wanderview> | and searching the spec for importScript does not reveal anything |
| 22:28 | slightlyoff | looks |
| 22:28 | <slightlyoff> | yeah, I'm not sure we spec'd it, so having it open does seem right |
| 22:28 | <wanderview> | sorry if its obvious and I missed it |
| 22:29 | <wanderview> | it sounds like its just a best effort caching... when the ServiceWorker script loads something through importScript()... put it in the cache |
| 22:29 | <slightlyoff> | or behavior (Blink) is to cache resources requested at initial download time (via importScripts) alongside the SW script version |
| 22:29 | <slightlyoff> | and the dependencies are only updated when the SW script updates |
| 22:29 | <wanderview> | slightlyoff: for delayed importScripts... it does not cache? |
| 22:29 | <slightlyoff> | (e.g., you run through an upgrade) |
| 22:29 | <wanderview> | or thats just best effort |
| 22:29 | <slightlyoff> | wanderview: I don't think we cache. |
| 22:30 | <wanderview> | hmm |
| 22:30 | <slightlyoff> | wanderview: at least not more than the HTTP cache provides |
| 22:30 | <slightlyoff> | wanderview: and that's the intended behavior |
| 22:30 | <slightlyoff> | wanderview: you can do more eval()-ing cache'd content if you want to |
| 22:31 | <slightlyoff> | wanderview: but that's all very explicit, which is what we were going for in the design |
| 22:31 | <wanderview> | slightlyoff: in gecko, I'm not sure we have an easy way to tell the difference between top level importScripts() and delayed importScripts() |
| 22:31 | <slightlyoff> | you don't have some marker for the SW script that you're caching? |
| 22:32 | <slightlyoff> | i.e., do you have a way of storing the SW script that opts it out of HTTP cache eviction? |
| 22:32 | <slightlyoff> | I don't know it's a problem to cache other importScripts more aggressively |
| 22:32 | <wanderview> | slightlyoff: we definitely know which one is the SW script |
| 22:33 | <slightlyoff> | but I think we want to keep devs from depending on that |
| 22:33 | <wanderview> | I'm not 100% sure... but I think the importScripts all just come out of the js engine as "something called importScripts!"... we don't know which parent script called it |
| 22:33 | <slightlyoff> | otherwise it becomes nearly impossible to reason about what's going to work in your SW as a download error in an importScript can screw you entirely |
| 22:33 | wanderview | traces more code. |
| 22:34 | <slightlyoff> | how do you keep them with the same durability as the SW script? That's the only invariant we NEED to preserve |
| 22:34 | <wanderview> | slightlyoff: we are internally using the Cache API |
| 22:34 | <slightlyoff> | would be fatal to a site if it importscripts started failing but the main SW script were there |
| 22:34 | <slightlyoff> | wanderview: seems legit. Don't think you've got a problem here then. |
| 22:34 | <wanderview> | slightlyoff: right... we are keeping the importScripts as persistent as the SW script... |
| 22:35 | <wanderview> | slightlyoff: its just we may over-cache compared to blink |
| 22:35 | <wanderview> | for delayed importScripts |
| 22:35 | <wanderview> | its a subtle compatibility difference... hopefully it doesn't bite too many people |
| 22:36 | <slightlyoff> | I think that's fine; contra TabAtkins, we're going to understand install-time vs. post-install-time requests for imported scripts |
| 22:36 | <wanderview> | I guess the http cache being there also muddies the water... people may think its fully offlined, but its just an aging http cache |
| 22:36 | <slightlyoff> | TabAtkins: I don't think this is really that bad, though...do you? |
| 22:36 | <slightlyoff> | wanderview: I think our long-term solution will be devtools warnings about dynamic importScripts() calls |
| 22:37 | <TabAtkins> | I'm pretty sure everything you said agrees with what I said, so no, I don't think it's bad. ^_^ |
| 22:37 | <slightlyoff> | TabAtkins: ah, right, then I misunderstood you. Sorry! |
| 22:37 | <wanderview> | thanks for the help |
| 22:37 | <TabAtkins> | (I said that dynamic/delayed importScript() calls should instead be fetch()/cache, then import them when you're sure they've arrived.) |
| 22:38 | <slightlyoff> | TabAtkins: yeah, that's totally true |
| 22:38 | <slightlyoff> | will ping jungkees about getting this squred away. I think we only need to say that importScripts post-initial-download MAY be discarded by the UA |
| 22:39 | <slightlyoff> | wanderview: using the Cache API should prevent the real compat worry (in my mind), which is the scripts getting updated at different rates by UAs |
| 22:43 | <wanderview> | slightlyoff: I've been corrected by baku and nsm... we do have a way to implement the same "cache only top importScript() calls" |
| 22:43 | <wanderview> | we're going to do that |
| 22:43 | <slightlyoff> | rad! |
| 22:44 | slightlyoff | does happy compatibility dance |
| 22:44 | <wanderview> | yea, good to be compatible and I like knowing when we are done caching |
| 22:44 | <wanderview> | slightlyoff: so I guess formalize that behavior in the spec? |
| 22:44 | <slightlyoff> | yep! |
| 22:44 | <wanderview> | awesome, thanks! |
| 22:48 | <TabAtkins> | +1 |