| 00:00 | <MikeSmith> | rektide: positive vibrations |
| 00:06 | <rektide> | seeing an api key as the first thing in the sample for the latest greatest webspec... are there engineering specialized psychiatrists? |
| 00:06 | <rektide> | i want to be better, but i feel completely outgunned, unlistened to, with people driving things they want to drive with what seems to me like wanton disregard for all the good stuff we do have |
| 00:08 | <rektide> | i cant imagine a positive interaction cycle. unless i show up with something that works, that i've in my own time made happen, i have a hard time envisioning myself more than a receiver for someone elses vibrations |
| 00:12 | <MikeSmith> | rektide: yet other people are in there getting listened to and helping improve and fix things |
| 00:14 | <MikeSmith> | rektide: I think sometimes your rhetorical approach alienates people before they even have a chance to consider the substance of what you're proposing or the problems you're pointing out |
| 00:24 | <rektide> | I almost never see any serious spec realignments happen |
| 00:25 | <rektide> | I admittedly am far from a close follower, but coming back to most specs, they are from a consumer perspective or or less what they were when I saw them 6 months ago |
| 00:26 | <MikeSmith> | rektide: then I think you're not looking hard enough or you're not looking for the right things |
| 00:26 | <rektide> | I fully believe there's a lot of ahrd work and people getting things improved and fixed, but the molds get set, and ya'll should be thankful and delighted to have outsiders bringing up derivise by changes |
| 00:27 | <MikeSmith> | everybody's thankful for genuinely constructive feedback |
| 00:28 | <MikeSmith> | but nobody is thankful if somebody shows up and just shits all over everything and calls everybody idiots |
| 00:28 | <rektide> | well in this case i was very happy bringing shame down on this, yes. |
| 00:29 | <rektide> | but generally i try to hold my tongue and state some kind of stance that i think is important and i think is being overlooked |
| 00:29 | <rektide> | in a civil fashion |
| 00:30 | <MikeSmith> | well civility will get you a lot farther than shaming |
| 00:30 | <MikeSmith> | anyway I think if/when you can get Hixie's attention you might get more consideration |
| 00:31 | <MikeSmith> | because among other things I think he has thicker skin than the rest of us as far as this goes |
| 00:32 | <MikeSmith> | he doesn't often flip the bozo bit on anybody |
| 00:33 | <MikeSmith> | @poiuytds |
| 00:34 | <sambuddhabasu1> | can someone explain how iframe sandbox works? |
| 00:34 | <TabAtkins> | When someone is "very happy bringing shame down", that usually results in everyone immediately flipping their bozo bit. |
| 00:34 | <sambuddhabasu1> | Im trying for nested iframe to bypass CSP |
| 00:34 | <MikeSmith> | rektide: what TabAtkins just said |
| 00:34 | <TabAtkins> | sambuddhabasu1: The spec does a decent job of explaining it. What's confusing you? |
| 00:35 | <sambuddhabasu1> | TabAtkins: can you link me to it? |
| 00:35 | <TabAtkins> | sambuddhabasu1: https://html.spec.whatwg.org/multipage/embedded-content.html#attr-iframe-sandbox |
| 00:35 | <sambuddhabasu1> | TabAtkins: can you help me bypass CSP either by nested iframe |
| 00:35 | <sambuddhabasu1> | or by using the iframe srcdoc attribute |
| 00:35 | <TabAtkins> | What are you trying to bypass CSP for? |
| 00:36 | <TabAtkins> | (Also, I probably can't help; I haven't had to mess with CSP before.) |
| 00:36 | <sambuddhabasu1> | TabAtkins: im making a safari extension and will need it for that |
| 00:37 | <TabAtkins> | What specifically are you trying to do that is being blocked by CSP, I mean? |
| 00:37 | <sambuddhabasu1> | TabAtkins: Im trying to inject an iframe with src of that of a local file packaged in the safari extension |
| 00:37 | <sambuddhabasu1> | but look like, safari handles CSP differently and the sites need a safari-extension explicitly in the CSP header for the extension to work |
| 00:38 | <rektide> | TabAtkins: people had reactions to EME, thought it did bad un-web things and degraded something precious to them. i think you have to not deny me my own feelings, deny me the ability to act publically, in ways the working groups might not like as some kind of tribute i have to offer to also work inside the group calmly, collectedly, respectfully. |
| 00:38 | <TabAtkins> | Is CSP preventing some inline scripts from running, or something? |
| 00:40 | <sambuddhabasu1> | TabAtkins: CSP is not letting me load the safari extension local files itself :( |
| 00:40 | <TabAtkins> | rektide: I don't care about "denying" you anything. I'm just saying that if you're hostile, I'll ignore you, and lots of other people will do the same. |
| 00:40 | <TabAtkins> | sambuddhabasu1: Ah, I really can't help you there. I can at least tell you that srcdoc doesn't help vs anything else; it's the same as src="data:text/html,...", just with easier escaping rules. |
| 00:41 | <sambuddhabasu1> | TabAtkins: alright, thanks for letting me know that |
| 00:41 | <sambuddhabasu1> | do you know of anyone who can help me with this? TabAtkins |
| 00:41 | <TabAtkins> | No clue! Sorry. :( |
| 00:42 | <rektide> | TabAtkins: that comes off awfully seriously as a threat, a very big one |
| 00:42 | <TabAtkins> | rektide: Haha, ok. |
| 00:43 | <TabAtkins> | I don't think reasonable people would call "I don't want to listen to you if you're not willing to speak respectfully" a threat, but whatever. |
| 00:44 | <TabAtkins> | There's a lot of work to be done, and a lot of people to be interacted with, and I don't have time to deal with people throwing shade. |
| 00:44 | <rektide> | Well, it's just that the reactions i've gotten and what people have been talking to me about aren't interactions- |
| 00:44 | <TabAtkins> | That's some mental static I don't have to deal with, except in the most limited and extreme cases. |
| 00:44 | <rektide> | they me working through my mental anguish |
| 00:44 | <rektide> | publically on twitter |
| 00:45 | <TabAtkins> | rektide: I just looked back at some threads you commented in, and yeah, they're totes hostile, in a way that immediately makes me skip past them. |
| 00:45 | <rektide> | Yup I know. |
| 00:45 | <TabAtkins> | If you've got mental anguish, work through that on your own time. Come to the lists with a calm demeanor, or people will ignore or downplay you. |
| 00:46 | <TabAtkins> | This isn't a rough-and-tumble place. We don't truck with letting people be hostile just because they're contributing. |
| 00:47 | <rektide> | I don't have any qualm with any of that, or any of what you've said framed in terms of what happens on the list. |
| 00:48 | rektide | is cornered again |
| 00:49 | rektide | feels like he doesn't know the secret sign |
| 00:51 | <rektide> | i'm presuming Tab was talking about https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0257.html |
| 00:51 | <rektide> | as that's the first thing that shows up for me, and is a classic me example |
| 00:52 | <caitp-> | the secret sign is just finger horns |
| 00:52 | <caitp-> | gestured with your tongue out, of course |
| 00:52 | <rektide> | if i'm so obviously right, why is it so hard for me to make a 1/10th decent point |
| 00:53 | <rektide> | more shame rektide examples are welcome here, particularly if there's more to say than 'immediately makes me skip past them' |
| 00:55 | <rektide> | what do i do when i get 'first draft, more to come' https://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0283.html and then time passes and it's all haha jk https://github.com/w3c/push-api/issues/81 |
| 00:57 | <caitp-> | maybe you could get some big stakeholders on your side |
| 00:58 | <caitp-> | sort of like the way well funded lobbyists are able to get washington on their side |
| 01:00 | <rektide> | i just want to continue being right all the time, continue spending way less time than i should writing emails that poorly commincate little except for a sense of the dire emminating from my corner, and have everyone look at it and go- oh, it's rektide, we'd better fucking listen |
| 01:00 | <rektide> | i havent found any lobbyists here in DC that can help me with that |
| 01:06 | <caitp-> | to be right, you have to convince people you're right --- and the most convincing things are things that big stakeholders want, imo |
| 01:06 | <TabAtkins> | rektide: For example, your posts in the blink-dev Push API thread, where there was a random "403 'Fuck You' Forbidden", and then some weird hostile defense of that. |
| 01:07 | <TabAtkins> | Your comment in the webapps "What Am I Missing" thread are like *super* hostile. |
| 01:08 | <TabAtkins> | Your www-dom "MouseEvent-mouse" thread was fine, it just got ignored. That's not cool, you should ping it again. |
| 01:09 | <TabAtkins> | "[blink-dev] Discovery [extends: Intent to Implement: navigator.connect]" is weird - it feels vaguely hostile. |
| 01:09 | <TabAtkins> | That's just the first couple of threads that come up when I search for "rektide" in my gmail. |
| 01:11 | <rektide> | https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0486.html is the "What am I missing" thread |
| 01:13 | <caitp-> | so the main argument is "push api is opaque"? |
| 01:14 | <rektide> | i think the guys use case is great |
| 01:14 | <rektide> | he wanted to be able to host an http endpoint |
| 01:19 | <rektide> | by opaque i mean, there's no identity, no resource for what is pushed. i mean there's no headers to serve as envelope declaring what's inside. |
| 01:20 | <rektide> | "push api is opque" right now will do it for me, yes. |
| 01:21 | <rektide> | as a web developer, i've always been given the amazing ability to be talking about things. and i lose that ability with the push api. there's just stuff, blobs, showing up, undifferentiable at the transport layer. |
| 01:58 | <MikeSmith> | so this is the first time I've seen this one https://twitter.com/sideshowbarker/status/578373861147705344 |
| 01:58 | <MikeSmith> | https://pbs.twimg.com/media/CAbL9eCUgAAeRMB.png |
| 01:58 | <MikeSmith> | 「Your connection is private but someone on the network might be able to change the look of the page.」 |
| 01:58 | <MikeSmith> | only in Chrome, and only on mobile |
| 01:59 | <TabAtkins> | MikeSmith: How weird. No clue what that means. |
| 02:01 | <MikeSmith> | TabAtkins: pinged @__apf__ about it. I reckon she knows |
| 02:01 | <MikeSmith> | I'm running Chrome beta on Android |
| 02:01 | <MikeSmith> | maybe it's something new |
| 02:01 | <MikeSmith> | I'm running a version that was just released today |
| 02:09 | <MikeSmith> | hsivonen: upgrading to newest Apache HTTP client seems to have increased the number of requests per second the vnu servlet code can handle |
| 02:09 | <MikeSmith> | hsivonen: http://validator.w3.org/nu/stats.html |
| 02:10 | <MikeSmith> | hsivonen: atm showing around 4.02 validations per second on each instance |
| 02:11 | <MikeSmith> | hsivonen: vs around 3.2 before I did the upgrade |
| 02:16 | <MikeSmith> | rektide: the normal pattern is that initial feedback doesn't result in any changes |
| 02:16 | <MikeSmith> | it often takes some sustained (calm and civil) lobbying |
| 02:17 | <MikeSmith> | ask the responsive-images advocates about how they felt in the weeks after they first brought back their <picture> proposal to the browser projects |
| 02:18 | <MikeSmith> | rektide: you probably don't want to hear this but it seems like it often takes pretty much a year before you see others come around on some things |
| 02:19 | <MikeSmith> | but that's not a pattern unique to getting standards problems fixed |
| 02:19 | <MikeSmith> | cf. https://twitter.com/lgarron/status/576522491939536897 |
| 02:21 | <MikeSmith> | and there are other cases like when we spent I think at least 5 years trying to get the Apache web server project to change the non-conforming default content type that they were sending out |
| 02:23 | <MikeSmith> | and it's taken 5 years for blink to move DOM properties to prototypes where they're supposed to be |
| 02:24 | <MikeSmith> | and WebKit is still shipping broken behavior for that, with no sign they plan on fixing it any time soon |
| 02:25 | <MikeSmith> | so it's not you're talking to people who've had no big frustrations of their own waiting for others to come around to making things right |
| 05:04 | <paul_irish> | has anyone attempted spec'ing autofill behavior? specifically looking at what events should be expected |
| 05:09 | <paul_irish> | I see "autocomplete" event to fire on the form. but nothing for the fields. input? change? keyup? |
| 05:10 | <paul_irish> | the challenge is a lot of authors binding to keyup and I'm wondering if it's fair to send a synthetic keyup after autofill. (the alternative is wait till they also bind to oninput) |
| 07:19 | <seekadvice> | hi, am i at the right place ? the whatwg html..... |
| 07:26 | <seekadvice> | helloooooooo....... anybody here, this is my 1st time on this kind of communication, i need some advice......regarding html |
| 07:28 | <philipj> | seekadvice: well, ask away :) |
| 07:31 | <seekadvice> | i wanted to learn html, i am a novice programmer,, i was hit by the news of DRM in W3C,,, i was looking for an alternative and came by whatwg.org by mistake, , so now i am considering learning html,, just with out DRM, |
| 07:32 | <seekadvice> | i found this pdf on whatwg.org with 1250 pages,,,,, any easier method to learn html ? |
| 07:48 | <seekadvice> | oh well,,,,, thank you anyway,,,i think i found another source. |
| 08:38 | <Domenic> | Can we just make all "boolean-ish" attributes (but not actual boolean ones) accept true/false/yes/no/on/off? |
| 08:38 | <Domenic> | I guess we'd have to pick a canonical one for the reflection into script, and that might be backward-incompat... |
| 08:38 | <Domenic> | wait no they should all reflect as javascript booleans |
| 08:42 | <Domenic> | annevk: what is the author-visible implication of "this also impacts Request and the first step of HTTP network or cache fetch"? |
| 08:42 | <annevk> | Domenic: should be obvious for Request |
| 08:43 | <annevk> | Domenic: there's no implication for the latter I think, just mentioning it |
| 08:43 | <Domenic> | So, you mean that request.body will behave the same as res.body with respect to .clone()? |
| 08:44 | <annevk> | Domenic: at least on the service worker side, it's still not entirely clear to me how Request works on both sides without issue |
| 08:44 | <Domenic> | i really hope it does... |
| 08:45 | <Domenic> | Node has a messy ServerRequest vs. ClientRequest thing, at first I thought fetch would have to but then I was convinced we could avoid it. |
| 08:45 | <annevk> | Domenic: okay, I think the same is actually true for Response to some extent, e.g. you want to read from response, but you might also want to write to it from a service worker |
| 08:46 | <Domenic> | yes, definitely |
| 08:46 | <annevk> | Anyway, all I meant to say was that what goes for Response also goes Request |
| 08:46 | <annevk> | for ^ |
| 08:46 | <Domenic> | what we decided last time we talked about this is that the creator of a (Request|Response) gets to write to it, consumer gets to read |
| 08:46 | <Domenic> | ok cool |
| 08:48 | <Domenic> | some new security attack with caches, abstract sounds scary http://arxiv.org/pdf/1502.07373v2.pdf |
| 09:16 | <MikeSmith> | Domenic: hey there are some positive parts in there too |
| 09:16 | <MikeSmith> | "The fierce competition between different browser vendors resulted in an intense focus on improving Javascript performance. As a result, Javascript code performs in some scenarios on a level which is on par with that of native code." |
| 09:16 | <MikeSmith> | that part's nice |
| 09:17 | <annevk> | Yeah and now we have all the exploits of .exe :-P |
| 09:19 | <Domenic> | welp, might as well give up and add shared memory |
| 09:22 | <MikeSmith> | ah browser has to be new enough to support High Resolution Time |
| 09:23 | <MikeSmith> | "the actual resolution of this timestamp for Safari for MacOS was on the order of nanoseconds, while Internet Explorer for Windows had a 0.8µs resolution. Chrome, on the other hand, offered a uniform resolution of 1µ on all operating systems we tested" |
| 09:24 | <MikeSmith> | but iOS is safe because no High Resolution Time support |
| 09:24 | <MikeSmith> | " the Javascript level, it seems that somewhat reducing the resolution of the high-resolution timer will make this attack more difficult to launch" |
| 09:25 | <MikeSmith> | ** "A possible stopgap measure would be to restrict access to this timer to applications which gain the user’s consent" |
| 09:26 | <MikeSmith> | "(for example, by displaying a confirmation window)" |
| 09:26 | <MikeSmith> | who woulda thought |
| 09:27 | <MikeSmith> | ... that High Resolution Time would become a feature that's sufficiently powerful/dangerous enough to merit requiring user opt-in |
| 09:34 | <MikeSmith> | botie, inform plh of high interest to Web Perf WG, security exploit: http://arxiv.org/pdf/1502.07373v2.pdf "A possible stopgap measure would be to restrict access to the High Resolution Timer API to applications which gain the user’s consent (for example, by displaying a confirmation window)" |
| 09:34 | <botie> | will do |
| 09:34 | <MikeSmith> | oope |
| 09:47 | <annevk> | Well given the number of timing attacks we are already familiar with it's not super surprising |
| 09:47 | <annevk> | But yeah, given the number of APIs it seems more and more like we want to ask the user to what extent they trust a certain domain + lock combination |
| 11:33 | <francisco_> | JakeA: ping, i'm working with sw, trying to do send a postMessage back to a window, but the result from clients.matchAll() is an empty sequence, am I missing something? |
| 12:05 | <JakeA> | francisco_: in transit at the moment, but will take a look when I'm in the office. What version of Chrome? |
| 12:14 | <ondras> | hm, I have a .ttf font that has a printable character for code point U+0010 |
| 12:14 | <ondras> | I guess I am out of luck displaying that? |
| 12:43 | <zcorpan> | annevk: where is the normative bit for sending Origin for POSTs? "It is used for all HTTP fetches whose CORS flag is set as well as those where request's method is `POST`." |
| 12:43 | <zcorpan> | annevk: or is that up to specs that invoke fetch? |
| 12:46 | <annevk> | zcorpan: yeah |
| 12:46 | <annevk> | zcorpan: the idea is that they would set the force Origin flag or whatever it's called |
| 12:46 | <annevk> | zcorpan: I'm open to doing that some other way |
| 12:48 | <francisco_> | JakeA: 43.02337, having same problems in gecko :( ... so was wondering if was my code, but it looks a pretty straight forward use. meanwhile i can workaround it on gecko using broadcastchannel api, but didn't think how i can do the same on canary |
| 12:48 | <zcorpan> | annevk: thx |
| 12:50 | <zcorpan> | annevk: i dunno, given the note i had expected the algorithm to look at the method and insert Origin if it's POST, but maybe it's fine as is |
| 12:51 | <annevk> | Ooh, that note is describing the policy there seems to be some agreement around |
| 12:51 | <annevk> | Yeah, I agree that is somewhat confusing. Depends a bit on who reads the document. Could add something for specificationers. |
| 12:57 | <zcorpan> | that could be useful |
| 12:58 | <zcorpan> | on another note, why does sendBeacon use CORS instead of matching <form method=post> ? |
| 13:02 | <JakeA> | francisco_: is the code anywhere I can see? |
| 13:31 | <annevk> | zcorpan: custom payloads? |
| 13:31 | <annevk> | zcorpan: for the subset that matches <form method=post> they do the same, presumably |
| 13:32 | <annevk> | zcorpan: it's not like you need to look at the response with sendBeacon() |
| 13:34 | <zcorpan> | annevk: ah right. yeah i guess that makes sense |
| 13:35 | <zcorpan> | annevk: it's different in that sendBeacon will fail to follow redirects without CORS headers in the response |
| 13:35 | <annevk> | zcorpan: that's a good point |
| 13:36 | <annevk> | Web Performance WG did it rather rushed and without really understanding the networking principles and I guess I missed that bit... |
| 13:37 | <annevk> | meh |
| 13:37 | <zcorpan> | apparently blink still follows the redirect, so maybe we can change the spec |
| 13:38 | <zcorpan> | https://code.google.com/p/chromium/issues/detail?id=468527 |
| 14:00 | <annevk> | o_O |
| 14:07 | <francisco_> | JakeA: yup -> https://github.com/arcturus/serviceworkerware/blob/master/lib/sww.js#L150-L173 |
| 15:44 | <JakeA> | francisco_: I just went to https://jakearchibald.github.io/svgomg/, opened devtools, ran window.onmessage = function(e) { console.log(e) } |
| 15:44 | <JakeA> | francisco_: then chrome://serviceworker-internals/, inspect… |
| 15:45 | <JakeA> | francisco_: then clients.matchAll().then(function(c) { c[0].postMessage('hi') }) |
| 15:45 | <JakeA> | and that was logged in the window |
| 15:47 | <francisco_> | JakeA: thanks will give it a second try |
| 15:53 | <francisco_> | JakeA: no luck for me https://pastebin.mozilla.org/8826453 in mac 64bits 43.02337 |
| 15:58 | <JakeA> | francisco_: what's navigator.serviceWorker.controller of the page? |
| 16:00 | <francisco_> | JakeA: woops, is null, very null |
| 16:00 | <JakeA> | francisco_: What's the SW's scope? |
| 16:00 | <JakeA> | (and the page's url? I'm betting it's out of scope) |
| 16:01 | <francisco_> | JakeA: not specifying scope, and doing the request from the same page that installs the sw |
| 16:02 | <JakeA> | francisco_: that means the scops is './' resolved against the SW script url |
| 16:02 | <JakeA> | I'm guessing that makes the page out of scope |
| 16:02 | <JakeA> | francisco_: serviceworker-internals will tell you the calculated scope |
| 16:05 | <francisco_> | JakeA: right, http://localhost:8000/demo/ |
| 16:05 | <JakeA> | francisco_: but the SW *script* url? |
| 16:06 | <francisco_> | JakeA: you are totally right, it's outside the demo directory, despite that the registration is being done there |
| 16:06 | <JakeA> | francisco_: that's fine if it's /sw.js, but I guess it isn't? |
| 16:06 | <francisco_> | JakeA: it isent, is /lib/sw.js |
| 16:07 | <francisco_> | *isnt |
| 16:07 | <JakeA> | francisco_: ahh, so the scope is /lib/, which is why pages in /demo/ aren't showing up |
| 16:08 | <francisco_> | JakeA: \o/ |
| 16:08 | <JakeA> | francisco_: in future, clients.matchAll({includeUncontrolled: true}) would have shown that page, but Chrome doesn't support that yet |
| 16:10 | <francisco_> | JakeA: good to know, thanks a lot! |
| 16:11 | <JakeA> | francisco_: the SW script url is security-sensitive, see http://jakearchibald.com/2014/launching-sw-without-breaking-the-web/ (we went with option B) |
| 16:13 | <francisco_> | JakeA: could I have more than one sw handling different scopes? |
| 16:52 | <JakeA> | francisco_: yep! |
| 17:05 | <JakeA> | Domenic: promise.chain… any idea why we have that? |
| 17:11 | <TabAtkins> | JakeA: The guy who implemented Blink's promise support liked a different set of names, and decided to just say "fuck it, I'm shipping these instead". |
| 17:11 | <JakeA> | TabAtkins: hmm, yeah, I remember Promise.resolved etc. |
| 17:17 | <TabAtkins> | Dealing with all the randos in SVG who dont' give a shit about browsers is always amusing. |
| 17:40 | <wanderview> | JakeA: I was thinking about SWs that don't want fetch events again... can't the UA just detect this by looking to see if the SW script registered an onfetch handler during install? If it didn't then, just bypass all the network interception logic for that registration, etc |
| 17:40 | <wanderview> | in regards to the third goal from https://github.com/slightlyoff/ServiceWorker/issues/566 |
| 17:41 | <JakeA> | wanderview: annevk wasn't keen on that. I was |
| 17:41 | <TabAtkins> | wanderview: Registering an event handler cant' cause an observable behavior change. This is consistent across the web platform. |
| 17:42 | <TabAtkins> | You can obviously omit *actually firing the event* if no one's listening, but that's not observable. You shouldn't change anything that is possible to detect. |
| 17:43 | <wanderview> | TabAtkins: I don't think I suggested any observable change... just an optimization in UA for avoiding fetch event dispatch and network interception if the event would go to /dev/null anyway. |
| 17:43 | <TabAtkins> | Well yeah, that's an unobservable change - if nothing's around to see whether the intercept happened, you don't actually have to process it. |
| 17:44 | <Ms2ger> | If a tree falls in the forest... |
| 17:44 | <JakeA> | Problem is you need to spin up the SW to see if the listener is registered |
| 17:45 | <wanderview> | JakeA: that happens at install time, right? |
| 17:45 | <JakeA> | Just because it was registered last time it span up, doesn't mean it will be this time |
| 17:45 | <TabAtkins> | Well, no. You need to keep around a bool *associated with* the SW recording whether or not it ever registered an event handler. |
| 17:45 | <wanderview> | JakeA: in theory the state of the fetch event handler being setting could be persisted when the SW is shutdown |
| 17:46 | <JakeA> | imagine: if (Math.round(Math.random())) self.addEventListener('fetch', …) |
| 17:46 | <TabAtkins> | JakeA: I don't understand how it could be not registered suddenly, without having spun up at some point. |
| 17:46 | <TabAtkins> | JakeA: I'm not talking about static analysis. The SW does or doesn't register a fetch event listener. If it doesn't, it's not going to see any fetch events. So you dont' need to spin it up when network requests happen. |
| 17:47 | <wanderview> | JakeA: that is kind of undefined behavior, no? you have no guarantees how many times your SW script will be reloaded |
| 17:47 | <TabAtkins> | Because, without a fetch listener, *it can't react to the fetch*, so it can't change itself to register a fetch listener. |
| 17:47 | <TabAtkins> | It can only do new things at install time, and when responding to something. |
| 17:47 | <TabAtkins> | Unless I'm totally missing something. |
| 17:48 | <TabAtkins> | (Like, unless we added a "I just woke up" event since last time I looked, which would be a terrible idea.) |
| 17:48 | <wanderview> | yea... I think the random example above is assuming stuff outside the fetch event handler will run on network interception... but thats not in the spec |
| 17:49 | <wanderview> | for my limited understanding of the spec |
| 17:49 | <TabAtkins> | Definitely not, and if it did, that's terribly nondeterministic. |
| 17:49 | <JakeA> | TabAtkins: SW runs, Math.round(Math.random()) is false, fetch listener not attached. Fetch happens, if you spin up the SW now, a listener *might* be registered |
| 17:49 | <wanderview> | JakeA: how can script reliably depend on the behavior... the SW might not have shutdown and therefore would not get executed again? |
| 17:49 | <TabAtkins> | JakeA: So you let it run whatever rando code it wants upon wakeup? Putting code at the top of my SW file is effectively wrapped in a "onSpinUp" handler? |
| 17:50 | <wanderview> | where spin up may or may not happen |
| 17:50 | <wanderview> | this is making GC observable, right? |
| 17:50 | <JakeA> | TabAtkins: yes, how would you do it otherwise? |
| 17:50 | <JakeA> | I don't think so |
| 17:50 | <JakeA> | It's making SW startup observable |
| 17:51 | <wanderview> | JakeA: but you are saying SW startup should happen before a fetch event is handled... what guarantees that will run for every network interception? |
| 17:51 | <wanderview> | JakeA: what if the browser just never shutdown the SW (allowed AFAICT) |
| 17:51 | <JakeA> | wanderview: yeah that's fine |
| 17:51 | <TabAtkins> | JakeA: Okay, so we landed ourselves in nondeterminism hell. |
| 17:51 | <wanderview> | JakeA: scripts that depend on "spin up" are going to be broken in the real world |
| 17:51 | <TabAtkins> | We'll have to wake up the SW for *every* possible event it *might* be capable of handling, *forever*. |
| 17:51 | <wanderview> | spin up hook |
| 17:52 | <JakeA> | wanderview: totally agree |
| 17:52 | <TabAtkins> | Yeah, I give less than a fuck about scripts that implicitly depend on their "spinup" handler. Break 'em, they suck, who cares. Register your shit during install or face the possibility of never getting it registered. |
| 17:53 | <JakeA> | TabAtkins: install, activate and fetch are the only events that don't require another registration step |
| 17:53 | <TabAtkins> | Then either fix that (make fetch require an explicit registration) or stop caring about things that happen in the spinup handler. ^_^ |
| 17:54 | <JakeA> | Btw, I'm more than happy to say "If the SW has terminated, and the event wasn't registered on the last spin up, it won't be spun up for that event" |
| 17:54 | <JakeA> | TabAtkins: I think there's some misunderstanding here? What's your concern? |
| 17:54 | <TabAtkins> | I mean, either behavior is *consistent*. There's nothing requiring a SW to be spun up at random times. If it's not listening for an event, it has no way of knowing that it's missing them. |
| 17:57 | <TabAtkins> | JakeA: The concern, per #566, is that you have to spin up a SW on every fetch, *just in case* it registers a fetch handler in its spinup handler (that is, the top-level code not placed in an onfoo handler). |
| 17:57 | <wanderview> | JakeA: maybe this just falls in the unspec'd part of the life cycle of a SW? maybe we need language that says "when a SW is stopped, the state of the relevent event handlers is persisted and used to determine if the SW should be checked for future events"... or something like that |
| 17:58 | <TabAtkins> | Despite the complete nondeterminism here, because there's no way of knowing how many spinup events you'll get - it's possible to get 0 (the SW never gets killed), or one per second (constant killing/revival). |
| 17:58 | <JakeA> | TabAtkins: yeah, I'm happy to go for the "only spin up if event previously registered" behaviour. Non-deterministic event handlers within a ServiceWorker should be considered a bug |
| 17:58 | <TabAtkins> | Yeah. |
| 17:58 | <TabAtkins> | The important bit is that this *doesn't* violate the "no side-effects from event listening" rule. |
| 17:59 | <wanderview> | JakeA: is this a new spec issue or just #566? I can write a new issue if you want |
| 18:02 | <JakeA> | wanderview: I think that issue is fine |
| 18:03 | <wanderview> | thanks |
| 18:05 | <JakeA> | TabAtkins: wanderview: you wouldn't be able to add the listener, say, between 9am-5pm using Date.now() |
| 18:06 | <wanderview> | JakeA: don't we need to hook an alarm api into SW? |
| 18:06 | <JakeA> | Of course, if you wanted to do that, you'd add the listener and have the date check inside the listener |
| 18:06 | <JakeA> | wanderview: yeah, at some point |
| 18:07 | <wanderview> | JakeA: I'm having a hard time thinking of a non-nefarious reason to have time based network interception |
| 18:15 | <TabAtkins> | JakeA: You can't add a listener during a specific time anyway, because there's no guarantee that the SW will be spun up during that time. |
| 18:16 | <TabAtkins> | And if we add an alarm API, then it's totally fine - the SW is *guaranteed* to spin up at a particular time, and you're registering a fetch handler from within that handler. Everything's well-defined and deterministic. |
| 18:17 | <TabAtkins> | (You're still screwed if you stochastically register a fetch listener within the "spinup handler", though, because there's no guarantee that the SW will be freshly spun up when the alarm goes off; it might already be awake for some other reason.) |
| 18:24 | <JakeA> | wanderview: I was more thinking of other events like push, where the user may not want notifications during particular times. Of course the correct place to handle this is in the handler |
| 18:25 | <JakeA> | TabAtkins: well, at the moment the time based thing would work, as the SW is spun up, then the event is fired |
| 18:26 | <JakeA> | I guess a long-living SW would break that though |
| 18:26 | <wanderview> | JakeA: yea... i think for now they have to do it in the handler... an alarm api would let people do it in a more batter efficient way in the future |
| 18:26 | <TabAtkins> | JakeA: *Unless* the SW was already spun up for some other reason, yeah. |
| 18:26 | <TabAtkins> | So it's still completely undependable. |
| 18:28 | <JakeA> | Yeah. Seems fine to avoid spinning up if listener wasn't registered. It does mean that spin up behaviour changes depending on listeners, so it has a behavioural impact |
| 18:28 | <JakeA> | (But I'm fine with that) |
| 18:29 | <wanderview> | I guess we just have to convince annevk |
| 18:32 | <TabAtkins> | JakeA: Really, it's just that the "spin up handler" is completely non-deterministic and there's no way to know when it'll fire. |
| 18:37 | <TabAtkins> | It so happens that browsers use various signals, such as whether listeners are registered, to determine when to randomly fire the spinup event. |
