| 00:00 | <smaug____> | I'm pretty sure I've seen such |
| 00:00 | <smaug____> | https://bugs.webkit.org/show_bug.cgi?id=49739 |
| 00:01 | <TabAtkins> | We were trying to fix it pre-fork. I assume people on that side are also at least somewhat interested in fixing it. |
| 00:02 | <TabAtkins> | Problem is that we micro-optimized ourself into a corner, so it's hard to fix without perf regressions on popular benchmarks. |
| 00:02 | <smaug____> | especially now if blink has the fix too |
| 00:03 | <smaug____> | I could be wrong, but I think bz got gecko's attribute handling performance to be between webkit and blink while those two were using the wrong attribute setup, and gecko had the one spec'ed |
| 00:04 | <smaug____> | (IIRC webkit is the fastest, at least in some microbenchmarks ) |
| 00:24 | <MikeSmith> | TabAtkins: I hope the lesson has been learned about avoiding that "micro-optimized ourself into a corner" trap, so that another 5-year saga like this one doesn't end up happening again |
| 00:24 | <MikeSmith> | smaug____: thanks |
| 00:41 | <Domenic> | I am fuzzy on the details but I kind of remember recent WebKit releases doing halfway steps on this |
| 00:41 | <Domenic> | e.g. now they return getter/setters on introspection, but those getter/setters are very broken |
| 00:42 | <Domenic> | so if we interpret that optimistically then they are probably trying to move toward a fix |
| 00:51 | <MikeSmith> | Domenic: yeah there are some details along those lines in comments of the https://bugs.webkit.org/show_bug.cgi?id=49739 bug that smaug cited |
| 00:51 | <MikeSmith> | and at https://bugs.webkit.org/show_bug.cgi?id=141585 |
| 00:51 | <MikeSmith> | https://bugs.webkit.org/show_bug.cgi?id=140575 |
| 00:55 | <caitp-> | [18:40] <MikeSmith> I guess it at least affects the case where somebody's monkey-patching the prototype? << i brought up the webidl question because of a library being broken in webkit, assuming that little conversation followed from that |
| 00:55 | <MikeSmith> | caitp-: ah ok |
| 06:27 | <strugee> | Hixie: ping |
| 06:27 | <strugee> | we were going to talk about developers.whatwg.org? |
| 06:52 | <annevk> | espadrine: that's a bug |
| 06:54 | <annevk> | TabAtkins: status of converting DOM? |
| 08:02 | <annevk> | Domenic: I think the strategy of forever pending and maybe adding rejecting later is okay, though bz brings up a valid point |
| 08:03 | <annevk> | Domenic: "[I]s this sufficient to actually build a browser on top of fetch? How is the browser expected to implement things like the stop button or the request-killing on navigation, if not by effectively calling terminate() on all the fetches involved?" |
| 10:00 | <annevk> | hsivonen: your last tweet fails at grammar |
| 10:36 | <Seplonger> | ... |
| 11:03 | <annevk> | I should maybe write a post about CORS since the amount of people not grokking the same-origin policy is disturbing |
| 11:10 | <JakeA> | annevk: are you around this evening for a call about SW clients & postmessage? Monday otherwise? |
| 11:27 | <strugee> | /quit |
| 12:22 | <annevk> | JakeA: yeah, can do, though I don't really have any new thoughts |
| 12:54 | <Ms2ger> | SimonSapin, TabAtkins sold his house in Texas, IIRC |
| 12:54 | <SimonSapin> | oh, I see |
| 13:15 | <hsivonen> | annevk: yeah. it's annoying when a tweet becomes nonsensical due to proof reading failure after editing for 140 characters |
| 13:16 | <hsivonen> | annevk: also annoying to notice it after it has a reply |
| 13:46 | hemanth | : Superfluous Patterns of Javascript -> http://h3manth.com/new/blog/2015/superfluous-patterns-of-javascript/ |
| 15:14 | <TabAtkins> | Ms2ger: ??? What's the relevance of my house? |
| 15:15 | <TabAtkins> | Never mind, I see. |
| 15:25 | <JonathanNeal> | http://dev.w3.org/csswg/css-font-loading/ Is there a friendly guide out there to using this? I have a knack for hanging the entire browser when I pass a second parameter into new FontFace |
| 15:28 | <JonathanNeal> | A third parameter, rather. e.g. new FontFace(family, source, descriptor); where name is “Balto”, source is ‘local(“Balto”)’ and descriptor is { weight: ‘bold’ }. Totally hangs the page. Is it the browser, or am I not following the spec? |
| 16:41 | <terinjokes> | JakeA: just checking in to make sure you locked yourself in a room and wrote your talk |
| 16:52 | <JakeA> | terinjokes: I'm still massively behind, so I'll be working the weekend :/ |
| 16:55 | <terinjokes> | JakeA: bummer, but no worries |
| 16:56 | <Domenic> | annevk: OK, that makes me want to add rejectWith out of the gate |
| 17:02 | <JakeA> | Domenic: I did some mental flailing around fetchPromise https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75217729 - am I anywhere near? |
| 17:11 | <annevk> | Domenic: hah |
| 17:32 | <caitp-> | what ever happened to the network infor api? |
| 17:32 | <caitp-> | fell off the face of the earth? |
| 17:32 | <tantek> | overdesigned to the point of bloat death? |
| 17:33 | <caitp-> | looks pretty small as these things go, actually |
| 17:36 | <annevk> | The use cases were not compelling I believe |
| 17:36 | <annevk> | Been a while |
| 17:37 | <Hixie> | strugee: here onw |
| 17:37 | <Hixie> | now |
| 17:40 | <caitp-> | annevk it looks like it's implemented perfectly happy on mobile devices, are you saying service worker was probably a better approach? |
| 17:40 | <tantek> | annevk - the simple common use-case is, don't burn my mobile data with background network updates and crap. |
| 17:41 | <tantek> | ergo, the simple v0 API should be a boolean - navigator.NetworkInfo.IsMetered() |
| 17:41 | <Hixie> | annevk: btw did you see the web intents post-mortem post? |
| 17:41 | <tantek> | but noooooooo, people had to go and add all kinds of lower level plumbing details that frankly no real world web app builder actually cares about. |
| 17:43 | <tantek> | note that latest Android OS has this exact boolean feature for app devs, INCLUDING, a UI for users to toggle whether any particular wifi SSID is metered or not. |
| 17:43 | <tantek> | that really is all you need to cover the common use-case noted above. and that's all that a v0 network info api should include, ship, get interop on. |
| 17:44 | <tantek> | shove all the rest of the net info details to the next version |
| 17:44 | <caitp-> | that does seem pretty reasonable |
| 17:44 | <annevk> | Hixie: from Paul? I did |
| 17:44 | <Hixie> | annevk: cool |
| 17:44 | <tantek> | catip - it's too reasonable to actually succeed in a discussion beyond 2-3 people. |
| 17:44 | <annevk> | Hixie: having said that, I still haven't really cracked a flow that works well |
| 17:44 | <tantek> | then everyone starts yanking out their pet armchair dev requirements / wishlists etc. |
| 17:44 | <annevk> | Hixie: one of the big problems is also convincing service providers that they want decentralization |
| 17:44 | <Hixie> | annevk: heh yeah |
| 17:45 | <annevk> | Hixie: e.g. I Facebook and Twitter and such seem quite content with all the promotion across millions of properties |
| 17:45 | <caitp-> | well, you probably don't need to care exactly how your connection works, but you probably want to have some idea of whether it's a weak or strong connection |
| 17:45 | <annevk> | s/I// |
| 17:46 | <caitp-> | i can see people wanting that :> |
| 17:47 | <tantek> | catip - "can see people wanting" is a horrible way to design anything |
| 17:47 | <annevk> | Hixie: perhaps the way out is continuing to provide easy ways for sites to collaborate and share data client-side and hope patterns emerge |
| 17:47 | <Hixie> | annevk: yeah, i dunno. just thought it was an interesting and candid post-mortem. |
| 17:47 | <Hixie> | annevk: with good lessons. |
| 17:48 | <annevk> | Hixie: e.g. cross-origin workers, the service worker to service worker messaging |
| 17:48 | <annevk> | Hixie: yeah, that was real cool of him |
| 17:55 | <Domenic> | JakeA: on my to-do list for today :) |
| 18:01 | <JakeA> | Domenic: no rush, I'm sure it's full of fundamental misunderstandings |
| 18:04 | <jgraham> | Anyone know anything about the Chromium CI setup? |
| 18:04 | <jgraham> | Specifically which servers / ports are avaliable / default |
| 18:28 | <TabAtkins> | tantek: Some apps on my phone act differently on wifi vs cell, even when both are unmetered. |
| 18:29 | <tantek> | TabAtkins - interesting. which apps, and do you know how they tell? (i.e. do they measure the bandwidth, do they query a proprietary API?) |
| 18:29 | <annevk> | TabAtkins: DOM ping? |
| 18:29 | <tantek> | and what different behavior(s)? |
| 18:29 | <TabAtkins> | JonathanNeal: If you're getting browser hangs for any reason, it's a bug. In your partiucular case, it's *definitely* a bug. |
| 18:30 | <TabAtkins> | tantek: G+ gives me the option to only photo-sync while on wifi. |
| 18:30 | <TabAtkins> | annevk: Gonna try to finish today. :/ If you have any edits you need to make, though, feel free; I'll take the merge pain myself. |
| 18:30 | <annevk> | TabAtkins: nah, I'll be patient |
| 18:30 | <tantek> | TabAtkins: I hope that means non-metered wifi, otherwise it's still a problem |
| 18:31 | <annevk> | TabAtkins: though with continued nagging :p |
| 18:31 | <TabAtkins> | I mean, I guess it matters what you mean by "metered". I don't pay per Mb or anything, but I do have a 2.5Gb/month limit. |
| 18:31 | <TabAtkins> | annevk: That works too. ^_^ |
| 18:31 | <TabAtkins> | tantek: And yes, wifi is non-metered. |
| 18:33 | <caitp-> | well, it depends |
| 18:33 | <caitp-> | sometimes paid wifi gives you N megabytes, sometimes N minutes |
| 18:34 | <caitp-> | you wouldn't want to waste bandwidth on stuff you don't need |
| 18:37 | <annevk> | JakeA: Domenic: thanks for laying the groundwork on all the subclassing questions |
| 18:38 | <tantek> | TabAtkins: cool. Do you have that preference panel where you can toggle a switch next to each SSID as to whether it is metered or not? |
| 18:38 | <JakeA> | annevk: I'm all about the questions. Answers… not so much |
| 18:38 | <tantek> | I think it's in the latest Android OS update |
| 18:38 | <tantek> | (pretty new) |
| 18:38 | <TabAtkins> | annevk: So I was thinking about terminate() again, and I think GTOR is right - a cancelable thing is a Task, not a Promise. Luckily, a Task is a Promise subclass (I think it's literally a Liskov subclass, but even if not, it ducktypes as such). |
| 18:38 | <tantek> | caipt - correct on both accounts |
| 18:38 | <annevk> | JakeA: FWIW, with regards to AbortablePromise, the idea was to have FetchPromise and terminate() as method, and then introduce the more generic variant as a class inbetween later |
| 18:38 | <tantek> | caitp |
| 18:38 | <JakeA> | wfm |
| 18:39 | <TabAtkins> | All this really means is that chaining off of a Task returns Promises; you need a separate explicitly cloning method to return a Task with the same special abilities as the original one. |
| 18:39 | <TabAtkins> | So yeah, FetchPromise.then() returns a Promise, nice and easy. |
| 18:39 | <annevk> | TabAtkins: interesting idea |
| 18:39 | <annevk> | TabAtkins: I'm not sure that's how promise subclasses work though |
| 18:40 | <JakeA> | It isn't |
| 18:40 | <JakeA> | at the moment |
| 18:40 | <annevk> | TabAtkins: don't they do new this.constructor for .then()? |
| 18:40 | <TabAtkins> | tantek: No, I have no such toggle. |
| 18:40 | <JakeA> | They get their constructor from @@species, so I guess FetchPromise could set its @@species to Promise |
| 18:41 | <TabAtkins> | For predictability, though, you should have a way to convert Tasks into Promises; a Task is a Promise you can fuck with, and that's not an ability you want to give out normally. |
| 18:41 | <tantek> | Hmmm… ok then maybe I was looking at something beta. Um ok I won't say on who's device then. TabAtkins perhaps ask a co-worker to see their list of SSIDs preference screen on their Android ;) |
| 18:41 | <JakeA> | But I like the idea of fetch(url).then(r => r.json()) being abortable |
| 18:41 | <TabAtkins> | Not all Promise subclasses are Tasks; most can reconstruct an instance of the same class no problem. |
| 18:41 | <annevk> | JakeA: I guess you'd have to do fetch(url).specialThen(...) instead |
| 18:41 | <annevk> | JakeA: if we adopt this Task idea |
| 18:42 | <TabAtkins> | If we wanna be decent about the theoretics of this, yeah. |
| 18:42 | <TabAtkins> | Rather than munging everything up and having trouble later when we want to do something more principled. |
| 18:42 | <TabAtkins> | (It's the difference between piping and broadcasting in Stream.) |
| 18:42 | <annevk> | otoh, tasks could also have a cloning .then(), and a .promise() for discarding responsibility... |
| 18:43 | <TabAtkins> | Yeah, that's another way. Depends on how you want the "default" behavior to work. |
| 18:43 | <TabAtkins> | Either way is defensible. |
| 18:45 | <JakeA> | So are we losing the ability for `var p = fetch(url1).then(_ => fetch(url2));` then later `p.abort()` to abort whichever request(s) are in flight? |
| 18:45 | <JakeA> | (not I'm particularly against that, just trying to understand) |
| 18:45 | <TabAtkins> | JakeA: You wouldn't be losing it regardless; question is just how you want the default semantics to work. |
| 18:46 | <TabAtkins> | Oh wait, though; I didn't know that the p1=>p2 aborting was a thing to preserve. |
| 18:46 | <TabAtkins> | Though monadically that seems okay. |
| 18:47 | <JakeA> | TabAtkins: This is just my mental flailing. Posted a finger-in-the-air set of expectations at https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75217729 |
| 18:48 | <annevk> | JakeA: for case 3 the expectation is that the promise is instead forever pending |
| 18:48 | <TabAtkins> | Let's assume that .then still returns a Task, and .promise() returns a Promise of it (losing the special abilities to fuck with the result). Then when .then() is combining a second FetchTask into the first, it can combine permissions, so that aborting one aborts all. |
| 18:48 | <annevk> | JakeA: not rejected due to canceling |
| 18:49 | <JakeA> | annevk: so cancelling doesn't reject? |
| 18:49 | <annevk> | JakeA: yeah, the desired default seems to be to not reject |
| 18:49 | <annevk> | JakeA: if you want to reject, use p.terminate({rejectWith: "heya"}) |
| 18:49 | <TabAtkins> | Case 3 seems slightly non-intuitive, and difficult to do. It requires tasks to control down-stream tasks too; we're now talking more of a stream than a promise. |
| 18:50 | <JakeA> | annevk: so an "await p" would just hang forever. That isn't what I'd expect but I haven't really thought it through |
| 18:51 | <annevk> | JakeA: https://annevankesteren.nl/2015/02/cancelable-promises has a summary and pointers |
| 18:51 | <JakeA> | TabAtkins: is you want to cast a promise subclass to a normal promise, Promise.resolve(subclassPromise) is the current way |
| 18:51 | <TabAtkins> | JakeA: Well, until the method got aborted. |
| 18:51 | <TabAtkins> | JakeA: All right. |
| 18:56 | <JakeA> | annevk: yeah, ok, I think that makes sense. I've actually got some hacky code in SVGOMG because of promises that reject following aborting https://github.com/jakearchibald/svgomg/blob/9d23d77e389d62beb7acd16413a13328e568bdfd/src/js/page/main-controller.js#L217 |
| 19:01 | <annevk> | JakeA: hah, that's exactly Domenic's prediction |
| 19:01 | <annevk> | JakeA: people writing if(e instanceof CancelableError) return |
| 19:03 | <Domenic> | @@species returns this so it automatically will return FetchPromise |
| 19:03 | <JakeA> | annevk: However, I do want to stop a spinner on cancellation, which pending forever won't support |
| 19:03 | <Domenic> | To convert tasks to promises do Promise.resolve(task) |
| 19:04 | <JakeA> | Problem with @@species is you lose the link to the original fetch, since @@species is got from this.constructor rather than this |
| 19:05 | <annevk> | JakeA: in that case use rejectWith I guess |
| 19:05 | <TabAtkins> | You gotta define a special .then() to get the right behavior, I think. |
| 19:06 | <JakeA> | annevk: yeah, so I'd be back to my if-instanceOf. Hmm |
| 19:06 | <TabAtkins> | So you can set the right internal slots, etc. |
| 19:07 | <JakeA> | TabAtkins: I came to that conclusion in https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75217729 - but feels cleaner if @@species was got from `this` |
| 19:07 | <JakeA> | (and Promise would define it on the prototype chain) |
| 19:07 | <TabAtkins> | But you lose the ability to cancel the fetch, or to combine fetches into a single cancelable thing. |
| 19:08 | <TabAtkins> | Ugh, if you want fetches to stack like that, we really do need to be more strict about it being a Task, and .then() being the Promise-returning method. |
| 19:09 | <JakeA> | Do you? Couldn't this.@@species carry over the state from this |
| 19:09 | <TabAtkins> | Because it's not cool if you chain two separate fetches off of a parent fetch, abort one of the children, and that causes the parent to abort. |
| 19:09 | <JakeA> | I guess it couldn't if it was called as a constructor |
| 19:09 | <JakeA> | hm, that's a good point |
| 19:09 | <JakeA> | Going to add that to the github issue |
| 19:10 | <TabAtkins> | You need to explicitly clone the parent fetch, so it can refcount itself and only abort itself if all the chained fetches abort. |
| 19:10 | <TabAtkins> | Again, this is stream-as-pipe vs stream-as-broadcast. If you want piping-like functionality, gotta be proper about it. |
| 19:11 | <TabAtkins> | If you try to mix it with the broadcast functionality, you're gonna have confused-deputy/ambient-authority bugs all over the place. |
| 19:12 | <JakeA> | https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75300556 |
| 19:25 | <Domenic> | if (instanceof) seems fine if you're going to do something besides just return and try to ignore it |
| 19:31 | <Domenic> | TabAtkins: lol "I'd link you, but I think I accidentally killed the spec;" |
| 20:30 | <TabAtkins> | annevk: I'm suddenly confused. DOM appears to have a dom-core.bs file now? |
| 20:30 | <TabAtkins> | The version I cloned originally only had Overview.src.html and dom-core.html |
| 20:37 | <TabAtkins> | annevk: I ask because I've been converting Overview.src.html into Overview.bs. |
| 20:38 | <TabAtkins> | Ah, looks like dom-core.bs is just a very light transliteration; not a ton of work went into it. Good. |
| 22:56 | <JonathanNeal> | Is there a native JS method to enumerate the device fonts? Simulation: http://sandbox.thewikies.com/document.fonts.enumerate/ |
| 23:15 | <Ms2ger> | JonathanNeal, that's a huge fingerprinting vector |
| 23:18 | <TabAtkins> | It's also already completely possible with high fidelity, so... |
| 23:19 | <TabAtkins> | It does indeed give you a bunch of identity bits, but you can't avoid it, since local font selection affects layout. |
| 23:19 | <TabAtkins> | JonathanNeal: I do plan to do *something* about querying local fonts in Font Loading. Just not sure what yet. |
| 23:47 | <zewt> | man, does anyone know if there's a switch somewhere to unbreak user scripts in chrome |
| 23:54 | <TabAtkins> | They getting CSP'd? |
| 23:57 | <JonathanNeal> | TabAtkins: what did you and Ms2ger mean by huge fingerprinting vector? |
| 23:58 | <TabAtkins> | That it expose a huge source of identity bits. The precise set of fonts you have on your system is pretty unique. |
| 23:59 | <JonathanNeal> | Right! |