| 01:55 | <rniwa> | MikeSmith: hi |
| 01:56 | <rniwa> | Hixie_: yt? |
| 02:06 | <Hixie_> | rniwa: vaguely |
| 02:07 | <rniwa> | Hixie_: did you see my thread about async iframe load? |
| 02:07 | <rniwa> | Hixie_: I'd appreciate your help if could either clarify the currently spec'ed behavior |
| 02:07 | <rniwa> | Hixie_: or if you can change the spec to either one of existing behaviors (except sync behavior webkit/blink browsers exhibit) |
| 02:07 | <rniwa> | i.e. either IE or FF behavior |
| 03:17 | <zewt> | cool, youtube managed to break scrolling in chrome on macs |
| 03:17 | <zewt> | on the trackpad, anyway |
| 03:32 | <Hixie_> | rniwa: in whatwg@? |
| 03:33 | <Hixie_> | rniwa: i haven't looked in detail, but as far as i can tell, the last e-mail describes what the spec does? |
| 03:34 | <Hixie_> | rniwa: i'll try to look tomorrow |
| 03:34 | <Hixie_> | rniwa: (remind me when you get online tomorrow so i don't forget!) |
| 04:19 | <rniwa> | Hixie_: okay, thanks |
| 07:30 | <zcorpan> | was there tests for reflecting attributes somewhere? |
| 07:33 | zcorpan | finds https://github.com/w3c/web-platform-tests/blob/master/html/dom/elements-metadata.js |
| 07:34 | <Ms2ger> | Right, Aryeh's |
| 07:46 | <MikeSmith> | there is no standard for document.charset, right? |
| 07:47 | <MikeSmith> | should be document.charsetSet per the Encoding spec? |
| 07:48 | <Ms2ger> | I think the standard is "drop it" |
| 07:49 | <Ms2ger> | http://w3c-test.org/web-platform-tests/master/dom/historical.html agrees |
| 07:50 | <MikeSmith> | Ms2ger: ok |
| 07:51 | <MikeSmith> | but document.charsetSet isn't historical though |
| 07:51 | <MikeSmith> | it's current per the Encoding spec |
| 07:51 | <MikeSmith> | right? |
| 07:51 | <Ms2ger> | That's specced in DOM |
| 07:51 | <MikeSmith> | oh |
| 07:52 | <MikeSmith> | thanks |
| 07:52 | <Ms2ger> | Np |
| 07:55 | <zcorpan> | any opinions about https://www.w3.org/Bugs/Public/show_bug.cgi?id=23627 Move offsetParent et al from HTMLElement to Element? |
| 08:09 | <MikeSmith> | zcorpan: why? |
| 08:10 | <zcorpan> | blink does it |
| 08:10 | <MikeSmith> | why does Blink implement them that way? |
| 08:10 | <zcorpan> | oh, dunno |
| 08:10 | <MikeSmith> | I wonder if it'd prudent to assume they have good reason.. |
| 08:10 | <zcorpan> | maybe someone thought they'd be useful on <svg> elements? |
| 08:11 | <zcorpan> | or maybe it was just the way it was implemented way back when |
| 08:11 | <zcorpan> | wonder what ie does |
| 08:12 | <MikeSmith> | it seems like there's probably no downside to moving them |
| 08:13 | <zcorpan> | presto has them on Element too |
| 08:16 | <zcorpan> | oops, forgot the doctype when testing ie |
| 08:20 | <zcorpan> | only HTMLElement in ie9/10 |
| 08:23 | <zcorpan> | annevk-cloud: ping https://critic.hoppipolla.co.uk/r/300 |
| 08:29 | <MikeSmith> | what if anything does testharness.js actually use meta@assert for? |
| 08:31 | <MikeSmith> | meta@name=assert |
| 08:42 | <zcorpan> | testharness.js itself doesn't use it i think |
| 08:51 | <MikeSmith> | zcorpan: ok |
| 08:56 | <MikeSmith> | so after re-trying to use github for test-review comments I don't think I'll do that any more because it makes me remember why critic is better |
| 08:57 | <MikeSmith> | sorry tobie |
| 09:00 | <MikeSmith> | critic is better both for the reviewers and for the people submitting tests for review |
| 09:00 | <MikeSmith> | the built-in github stuff is not a review system, it's a commenting system |
| 10:03 | <annevk> | zcorpan: offset* is quite a terrible API, that's why it's defined on HTMLElement |
| 10:03 | <annevk> | zcorpan: sorry about the URL tests :/ |
| 10:09 | <zcorpan> | annevk: ok |
| 10:38 | <darobin> | MikeSmith: yeah, I just wish the frontend code for Critic were separated from the backend so that it would be easier to tweak and improve it |
| 10:42 | <MikeSmith> | darobin: I wish the critic UI sucked less so there'd be no need to spend much time improving it :) |
| 10:44 | <jgraham> | after a while you stop noticing the UI |
| 10:44 | <jgraham> | Like the matrix |
| 10:45 | <darobin> | MikeSmith: heh, yeah |
| 10:45 | <jgraham> | Except that in this case you mostly see "issue", "bug", "bad whitespace" |
| 10:45 | <darobin> | jgraham: I'm not quite there yet... |
| 10:45 | <jgraham> | Which is quite a bit less exciting ;) |
| 10:45 | <darobin> | Issue Smith |
| 10:46 | <jgraham> | (I agree that the UI could be improved, and that the particular nature of the code makes this less easy to achieve than it could be) |
| 10:48 | <darobin> | jgraham: yeah, I poked through the code to see if I could do something, but all the HTML is pretty much hardcoded |
| 10:48 | <jgraham> | (but the flip side is that it went from "doesn't exist" to "better than any other code review system we tried at Opera" in a few months) |
| 10:48 | <darobin> | yeah, I'm not dissing it |
| 10:48 | <darobin> | just a bit annoyed that I can't tweak it without starting from a major refactoring |
| 10:50 | <jgraham> | Well the HTML is hardcoded in the sense that it uses a kind of code-based HTML generation system that goes in a python file rather than in an external template |
| 10:50 | <MikeSmith> | darobin: I think I'm not there yet either. It's like the scene in the Blues Brothers where Jake finds out a noisy train runs just a few feet away right outside to the window of the bed where he needs to sleep, and he says, How often does the train come by? and then Elwood says, So often you won't even notice it. |
| 10:50 | <darobin> | MikeSmith: lol |
| 10:51 | <darobin> | jgraham: that's pretty hardcoded :) |
| 10:53 | <jgraham> | I will grant you that it doesn't have a clear template/controller seperation |
| 10:57 | <darobin> | ideally, for things that are really apps like this, I prefer to have a backend that does nothing more than provide a JSON interface, and let the frontend handle all of the UI on the client |
| 10:58 | <darobin> | basically move everything from PAGES into OPERATIONS |
| 10:58 | <darobin> | the one thing it makes harder is extensions |
| 11:00 | <jgraham> | So someone made a backend that exposed the data as JSON |
| 11:00 | <jgraham> | *extension |
| 11:01 | <jgraham> | Anyway, I guess if you are serious about working on this you should talk to jl |
| 11:01 | <darobin> | oh, you mean that exposes all the things currently done as pages using an API? that's pretty cool |
| 11:01 | <darobin> | well, I'm half-serious |
| 11:01 | <darobin> | I would be serious if I had more bandwidth |
| 11:01 | <darobin> | I certainly don't have the bandwidth to do a full refactor |
| 11:02 | <darobin> | but if there's an extension that at least exposes everything as JSON, I could possibly find the time to hack a UI |
| 11:02 | <jgraham> | Well, like I say you should talk to jl |
| 11:03 | <darobin> | where's jl? |
| 11:03 | <jgraham> | @opera.com |
| 11:04 | <darobin> | ah, gotcha |
| 11:04 | <darobin> | do you know where that extension is? |
| 11:04 | <jgraham> | I don't know if it was ever released anywhere. I don't remember who made it |
| 11:05 | <molsson> | I think it was Alexey Feldgendler that did the JSON extension |
| 11:51 | <MikeSmith> | so if the Notification API does end up being exposed to workers, I guess that'd actually make Notification.permission useful for something |
| 11:53 | <MikeSmith> | for the normal case I still don't see when it's actually ever necessary to directly check .permission rather than just calling requestPermission and having it automatically check the permission state |
| 12:08 | <MikeSmith> | zcorpan: about https://www.w3.org/Bugs/Public/show_bug.cgi?id=23627 is there a precedent for moving members from HTMLElement to Element? |
| 12:08 | <zcorpan> | MikeSmith: yeah, e.g. id |
| 12:09 | <zcorpan> | innerHTML |
| 12:09 | <MikeSmith> | ok |
| 12:23 | <MikeSmith> | anybody here build chromium from sources in the last couple days? |
| 12:23 | <MikeSmith> | I asked this on #chromium but didn't get any response |
| 12:23 | <MikeSmith> | gclient sync is failing for me with "Fetching origin... error: index-pack died of signal 10... fatal: index-pack failed" |
| 12:27 | <annevk> | https://twitter.com/antimattur/status/393714996951011328 <3 |
| 12:31 | <MikeSmith> | so that explains those glasses that HT wears |
| 12:36 | <zcorpan> | TabAtkins: a comment above the h1 makes bikeshed not read the h1 |
| 12:58 | <annevk> | Hixie_: fffuuu |
| 12:59 | <annevk> | Hixie_: it's not classList.has; it's classList.contains() |
| 13:35 | <darobin> | wow, I had no idea that someone had reused the Horse JS engine on mattur |
| 13:37 | <annevk> | Pretty sure animattur and mattur are authored by the same person. |
| 13:42 | <zcorpan> | MikeSmith: are you able to fiddle with repo permissions? i want push access to the FXTF repo |
| 13:42 | <MikeSmith> | zcorpan: |
| 13:43 | <MikeSmith> | |
| 13:43 | zcorpan | nods |
| 13:43 | <MikeSmith> | zcorpan: yeah I can but away from PC now |
| 13:43 | <zcorpan> | ok, no rush :-) |
| 13:44 | <MikeSmith> | will be beck in about 90 minutes |
| 14:04 | <darobin> | bah, clicked a link by mistake, lost my critic review :( |
| 14:06 | <darobin> | ah, no, it only half lost the review... |
| 14:17 | <jgraham> | darobin: Which review? |
| 14:18 | <darobin> | your big python change |
| 14:19 | <darobin> | and mostly sputtering at critic :) |
| 14:20 | <darobin> | jumping between the list of files and the code view is driving me positively insane |
| 14:21 | <darobin> | jgraham: there seem to be quite a few changes in there that aren't related to the functionality |
| 14:24 | <Hixie_> | annevk: try now |
| 14:24 | <jgraham> | darobin: Yeah, for reviews that have a lot of changes that does get pretty annoying |
| 14:24 | <jgraham> | Well a lot of files changed |
| 14:25 | <jgraham> | Which changes are unrelated? |
| 14:25 | <jgraham> | I made some fixes to tests that were brokwn |
| 14:27 | <darobin> | jgraham: I don't know, right now I'm just going through the bits that seem obvious to get them out of the way |
| 14:28 | <darobin> | I saw some fixes that are indeed good fixes, but don't touch PHP->PY in any way |
| 14:28 | <darobin> | I mean, it's great that you're fixing tests too, but it would make a large review like that easier if you did so separately :) |
| 14:29 | <darobin> | also, some files seem to have seen only white space change |
| 14:29 | <jgraham> | darobin: Yeah, but it would also have been a nightmare to actually make the changes :) |
| 14:30 | <darobin> | fair enough, I'm not complaining, just bitching because I'm getting seasick from all the scrolling critic is putting me through |
| 14:30 | <darobin> | I wish the code view just opened under the file, or at least that there were a link back to the position in the list |
| 14:30 | <jgraham> | The errors I fixed were spotted because I was running the tests which required the changes needed to run the tests |
| 14:30 | <jgraham> | Yes, I totally agree |
| 14:31 | <zewt> | ffff i need FileSaver |
| 14:31 | <darobin> | jgraham: what is utils.js's token() used for? |
| 14:32 | <darobin> | oh, it's a uuid generator |
| 14:32 | <jgraham> | darobin: Yes |
| 14:32 | <jgraham> | It's needed for the stash stuff |
| 14:32 | <jgraham> | You have to pass in a uuid |
| 14:32 | <jgraham> | (as they key) |
| 14:37 | <jgraham> | darobin: Checking things are per-spec isn't really in the spirit of testing :) |
| 14:38 | <zewt> | heh, aw snap'd chrome with a data: url |
| 14:38 | <Ms2ger> | jgraham, eh? |
| 14:42 | <darobin> | jgraham: wait, what? |
| 14:42 | <jgraham> | Oh, I see that sentence didn't make sense outside my head |
| 14:42 | <Ms2ger> | It did make sense there? |
| 14:43 | <jgraham> | I mean only allowing spec-conformant input as part of tets isn't really in the spirit of testing |
| 14:43 | <Ms2ger> | Yes, but that's not what you said ;) |
| 14:43 | <jgraham> | c.f. http://critic.hoppipolla.co.uk/showcomment?chain=653 |
| 14:44 | <jgraham> | Well it is if you assume that "things" are "inputs" |
| 14:44 | <Ms2ger> | Maybe |
| 14:46 | <jgraham> | Anyway, to distract you from my inability to form a coherent sentence http://hoppipolla.co.uk/410/coverage/ |
| 14:46 | <jgraham> | Might be the coverage from running all the web-platform-tests |
| 14:47 | <darobin> | jgraham: oh, that |
| 14:47 | <darobin> | jgraham: that's why I phrased it as a question (admittedly, that could have been clearer outside my head, too) |
| 14:47 | <Ms2ger> | jgraham, that sucks :) |
| 14:48 | <jgraham> | (obviously most of this data is not useful. Would be good to figure out what the right set of files/modules to include would be) |
| 14:48 | <darobin> | if it's meant to be a friendly helper that gives you a redirect when you need one, then it should test that you're asking for something sensible |
| 14:48 | <darobin> | but if it's meant to be a nasty thing that checks you're not doing stupid stuff on redirects, then indeed it should just do whatever :) |
| 14:48 | <darobin> | I just couldn't figure out which just from looking at it |
| 14:49 | <jgraham> | I think it's OK for it to have sharp edges |
| 14:49 | <Ms2ger> | Also implausible |
| 14:49 | <darobin> | jgraham: rofl, I love what you did with the red there |
| 14:49 | <Ms2ger> | No tests that get htmlelement.title? |
| 14:50 | <Ms2ger> | jgraham, does that include the reflection tests? |
| 14:50 | <jgraham> | Ms2ger: Hmm. did I mention that I only just generated this data |
| 14:50 | <jgraham> | And haven't looked at it yet :) |
| 14:50 | <Ms2ger> | jgraham, well, I don't believe what I see ;) |
| 14:50 | <jgraham> | And might well have some it wrong :) |
| 14:53 | <jgraham> | It should in theory have included everything. But maybe gcov gets upset with multiple processes writing the files at the same time? |
| 14:55 | <annevk> | Hixie_: works, ta! |
| 14:55 | <Ms2ger> | That seems plausible |
| 14:55 | <jgraham> | It does. Sadly it takes an hour to run all the tests one at a time |
| 14:55 | <jgraham> | But I guess I'm not going anywhere for the next hour! |
| 14:57 | <annevk> | darobin: https://critic.hoppipolla.co.uk/showcomment?chain=653 you don't wanna do that |
| 15:00 | <annevk> | darobin: e.g. you want to test 702 with a Location header and observe it not following the redirect |
| 15:02 | <jgraham> | Yeah, so I think that the issue about needing a docstring is fair |
| 15:03 | <darobin> | I'm pretty sure it won't be too taxing for your coding ability |
| 15:03 | <darobin> | heh, according to Critic 32% done, 67% remaining — gotta love computers |
| 15:04 | <wilhelm> | It may be philosophical. Nothing is ever _done_. |
| 15:04 | <jgraham> | It's quite fun when it decides something is 99.999% done |
| 15:05 | <jgraham> | In my experience, those reviews never are :) |
| 15:15 | <jgraham> | darobin: Thanks for all your review btw |
| 15:24 | <darobin> | jgraham: no worries, thanks for coding it up in the first place |
| 15:24 | <darobin> | I can tell you had a blast updating the websockets tests |
| 15:33 | <annevk> | If you say, return all of list X with each of X separated by Y. Does that imply you return nothing if X is empty? |
| 15:35 | <Ms2ger> | Sure |
| 15:35 | <annevk> | Well I guess that's what it said today, so I'll go with that for now. |
| 15:43 | MikeSmith | looks around for zcorpan |
| 15:44 | <annevk> | https://dvcs.w3.org/hg/xhr looks kinda scary |
| 15:45 | <annevk> | MikeSmith: any chance the description field for XHR can also mention xhr.spec.whatwg.org? |
| 15:45 | <MikeSmith> | "Initial commit for Level 1." |
| 15:46 | <MikeSmith> | annevk: sure |
| 15:48 | <annevk> | MikeSmith: seems you might also want to fix the owner of that dvcs.w3.org component if you care |
| 15:48 | <MikeSmith> | will do |
| 15:52 | <MikeSmith> | annevk: check the description now |
| 15:52 | <MikeSmith> | that probably won't get me in any trouble |
| 15:53 | <MikeSmith> | good thing we didn't have this conversation on a public channel where somebody could point plh to the logs when they complain |
| 15:54 | MikeSmith | will change the owner part now |
| 15:54 | <Ms2ger> | Interesting |
| 16:12 | <MikeSmith> | "an all-sing, all-dance script of amazingness" https://groups.google.com/a/chromium.org/d/msg/blink-dev/fnWX8n6JrTg/iCwZ8mmOBdUJ |
| 16:14 | <annevk> | So in particular https://dvcs.w3.org/hg/xhr seems to now have descended into monkey patching hell where they take some fixes and not others and don't even discuss that on the list |
| 16:15 | <jgraham> | Woah |
| 16:15 | <jgraham> | Is Dirke not on public-test-infra? |
| 16:20 | <MikeSmith> | jgraham: he is |
| 16:20 | <MikeSmith> | at least his e-mail address is |
| 16:20 | <MikeSmith> | @chromium.org |
| 16:23 | <jgraham> | Interesting |
| 16:23 | <MikeSmith> | jgraham: oh I guess you're reading the blink-dev thread |
| 16:23 | <jgraham> | MikeSmith: Yes |
| 16:23 | <MikeSmith> | mention of PHO |
| 16:23 | <jgraham> | Although I now have a read/write relationship with it |
| 16:24 | <MikeSmith> | aka PHP |
| 16:24 | <MikeSmith> | jgraham: time to use the write function :-) |
| 16:24 | <MikeSmith> | oh you did |
| 16:25 | <jgraham> | Yes |
| 16:25 | <jgraham> | But it's nice to know that you got it |
| 16:25 | <jgraham> | I don't really trust Google Groups |
| 16:25 | <jgraham> | s/ Groups/ |
| 16:25 | <annevk> | I got it, via email |
| 16:28 | <MikeSmith> | speaking of mailing lists, for following Web-platform-related work in Gecko, what lists might should I be on along with dev-platform⊙lmo? |
| 16:28 | <Ms2ger> | There's some smaller ones... m.d.t.layout, perhaps |
| 16:29 | <Ms2ger> | Maybe m.d.servo |
| 16:32 | <MikeSmith> | Ms2ger: ok |
| 16:33 | <annevk> | I wish dev.platform was a bit more focused |
| 16:36 | <MikeSmith> | it does seem to cover a lot more ground than other browser-engine -dev lists |
| 16:36 | <MikeSmith> | not that it's uninteresting |
| 16:44 | <Ms2ger> | Here's the spec: |
| 16:44 | <Ms2ger> | http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_targetmodule |
| 16:44 | <Ms2ger> | With quote marks around it, of course |
| 16:58 | <annevk> | http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0067.html "W3C web platform" oh god |
| 16:58 | <annevk> | I think it's time to go home |
| 17:00 | <Jasper> | i really hate that encrypted content is called premium content |
| 17:01 | <Jasper> | like, I don't really care about EME that much. it's a necessary evil imo. but "premium content" just pushes my buttons |
| 17:01 | <hober> | i think every single term that people have come up with press someone's buttons |
| 17:02 | <hober> | so it's best not to bikeshed it too much |
| 17:02 | <Jasper> | yeah, that's true |
| 17:02 | <jgraham> | Well, in this case "Premium Content" is basically advertising from netflix |
| 17:02 | <Jasper> | not trying to change anything, just sort of ranting off-topic |
| 17:03 | <annevk> | Giving web platform gets qualifiers seems way worse... Anyway... |
| 17:03 | <annevk> | s/gets// |
| 17:04 | <jgraham> | annevk: I think that was intended to have the opposite effect :) |
| 17:04 | <MikeSmith> | the VSOP Web Platform |
| 17:04 | <MikeSmith> | aged 20 years |
| 17:05 | <Jasper> | enterprise web-scale platforce |
| 17:05 | <annevk> | XO is where it's at MikeSmith |
| 17:05 | <MikeSmith> | well I drink Old Crow and like it |
| 17:05 | <jgraham> | Nothing to do with the Vienna Symphonic Orchestra Project then? |
| 17:06 | <MikeSmith> | brandy confuses me |
| 17:07 | <Jasper> | it has everything to do with Vienna Symphonic Orchestra Project, jgraham |
| 17:12 | <MikeSmith> | long earthquake here |
| 17:12 | <MikeSmith> | seems to be getting stronger, oddly |
| 17:12 | <hober> | MikeSmith: :( |
| 17:13 | <MikeSmith> | http://quake.twiple.jp/quake/view/20131026021102 |
| 17:13 | <MikeSmith> | 7.3 it seems |
| 17:13 | <MikeSmith> | up in Fukushima |
| 17:40 | <bholley> | Hixie_: ping |
| 17:41 | <bholley> | jgraham: ping |
| 17:42 | Ms2ger | hides |
| 17:42 | <bholley> | Ms2ger: ping :-) |
| 17:43 | <Ms2ger> | Not here! |
| 17:43 | <bholley> | Ms2ger: do you know if any spec defines where we should cut off stack traces? |
| 17:43 | <bholley> | Ms2ger: like, when we spin the event loop, for example |
| 17:43 | <Ms2ger> | No idea |
| 17:43 | <bholley> | we obviously don't want stack traces to go all the way up |
| 17:44 | <Ms2ger> | TC39 wanted to maybe spec stacks, I think |
| 17:44 | <Ms2ger> | annevk, ^ |
| 17:44 | <Hixie_> | bholley: here |
| 17:44 | <bholley> | Hixie_: see my question above |
| 17:44 | <bholley> | Hixie_: I'd thought that this was specced in terms of the script entry point, but I don't see anything of the sort in the spec |
| 17:44 | <Hixie_> | bholley: i don't even know of a spec that requires stack traces in the first place |
| 17:45 | <bholley> | Hixie_: (new Error()).stack? |
| 17:45 | <Hixie_> | that's probably specced in JS land |
| 17:45 | <Ms2ger> | If it's specced at all by now |
| 17:45 | <bholley> | Hixie_: well, it's our problem now in HTML5 |
| 17:45 | <bholley> | Hixie_: because we specced an event loop |
| 17:45 | <Hixie_> | how does the event loop affect this? |
| 17:46 | <bholley> | Hixie_: well, if you spin an event loop |
| 17:46 | <bholley> | Hixie_: does your stack trace see through that? |
| 17:46 | <Domenic_> | yes please! |
| 17:46 | <Domenic_> | long stack traces would be a killer dev tools feature |
| 17:46 | <Hixie_> | bholley: that's defined in the spec |
| 17:46 | <Domenic_> | user-land libraries are emulating that right now using V8 stack trace API and duck-punching every async method to record the stack at call time then stitch it together with subsequent ones. |
| 17:47 | <bholley> | Hixie_: where? |
| 17:47 | <Hixie_> | bholley: spin the event loop actually doesn't do a nested event loop, per the spec. it ends the previous task entirely, saves off its current state in a continuation, and returns back to the original event loop. |
| 17:47 | <Hixie_> | bholley: then it queues a task when it's ready to resume, and the task resumes the previous state |
| 17:47 | <Hixie_> | bholley: so there's nothing unusual on the stack |
| 17:47 | <Hixie_> | http://www.whatwg.org/specs/web-apps/current-work/#spin-the-event-loop |
| 17:48 | <bholley> | Hixie_: so, per spec, stack traces don't see through nested event loops |
| 17:48 | <Hixie_> | right |
| 17:48 | <Hixie_> | cos there aren't any |
| 17:48 | <Hixie_> | "spin the event loop" is really "queue a continuation" |
| 17:49 | <bholley> | Hixie_: ok. And as far as the spec is concerned, there's no reason stack traces wouldn't see through event dispatches and whatnot? |
| 17:49 | <Hixie_> | well |
| 17:49 | <Hixie_> | i don't see anything in HTML that would say one way or the other |
| 17:49 | <Hixie_> | or DOM (which specs dispatches) |
| 17:49 | <Hixie_> | but |
| 17:49 | <Hixie_> | the real question |
| 17:49 | <Hixie_> | is what the spec for Error.stack is |
| 17:50 | <Hixie_> | and i can't find out |
| 17:50 | <Hixie_> | can't find one, even |
| 17:50 | <Domenic_> | there's a ES strawman |
| 17:50 | <Hixie_> | nothing in http://people.mozilla.org/~jorendorff/es6-draft.html#sec-properties-of-the-error-prototype-object or anywhere near it |
| 17:50 | <Domenic_> | didn't make the ES6 cutoff, too much edge-case debate IIRC |
| 17:50 | <Domenic_> | http://wiki.ecmascript.org/doku.php?id=strawman:error_stack |
| 17:50 | <bholley> | Domenic_: ok. So currently this stuff is unspecced, and we're still working it out? |
| 17:50 | <Ms2ger> | Ah, good old strawmen |
| 17:51 | Hixie_ | waves a "please join the living standard movement" flag near the ES spec's office |
| 17:51 | <Domenic_> | bholley: yeah, i mean, i don't know what the HTML spec says about it, but I know the ES spec says nothing about error.stack |
| 17:51 | <Hixie_> | bholley: personally i would define it as being only the stack trace from the point where JS thinks it was invoked |
| 17:51 | <Hixie_> | bholley: so dispatching an event would reset the stack for the "child" "program" |
| 17:52 | <Hixie_> | bholley: but authors may prefer something else |
| 17:52 | <Hixie_> | bholley: i guess if dispatchEvent() can never go cross-origin, it's probably more useful to include it |
| 17:53 | <Hixie_> | bholley: as for spinning the event loop... maybe have something hanging off the stack object that says "and btw, here's the stacks for the various things currently waiting in a "spin the event loop" algorithm" |
| 17:53 | <Hixie_> | bholley: though that _can_ be cross-origin |
| 17:53 | <Domenic_> | in user space we've preferred to have separators where the "async" boundaries live, e.g. https://github.com/kriskowal/q#long-stack-traces or https://github.com/tlrobinson/long-stack-traces/#usage |
| 17:53 | <bholley> | Hixie_: that seems logical to me. But doesn't appear to jive with the current behavior of Gecko and Blink. http://bit.ly/16ylHO2 |
| 17:53 | <Hixie_> | ah well if there's implementations and they're interoperable, i'd just go with that |
| 17:53 | <Hixie_> | (unless it's crazy) |
| 17:54 | <bholley> | Hixie_: well, I'm still trying to sort that part out |
| 17:55 | <bholley> | Domenic_: as in, formatting separators |
| 17:55 | <bholley> | Domenic_: I don't think we can cross async boundaries very easily in the platform |
| 17:56 | <bholley> | Hixie_: our long-term thinking was that we would just have one single stack |
| 17:56 | <bholley> | Hixie_: and filter out cross-origin stuff |
| 17:56 | <bholley> | which is probably what Domenic_ wants |
| 17:57 | <bholley> | Domenic_: would Blink be interested in implementing something like that? |
| 17:59 | <gsnedders> | Hixie_: Part of the problem with Error.stack is some things (Closure used to, maybe still does?) rely on subtly different formats based on UA strings. |
| 18:00 | <Hixie_> | ew |
| 18:00 | <Hixie_> | shouldn't it be a structured array of tuples |
| 18:00 | <Ms2ger> | Hah |
| 18:00 | <gsnedders> | Hixie_: And seem very hard to get changed (i.e., the Opera code still relies on Futhark behaviour, never having gotten changed for Carakan despite having had patches made for it) |
| 18:00 | <Hixie_> | isn't that codebase dead |
| 18:01 | <gsnedders> | Closure? |
| 18:01 | <gsnedders> | Haha. No. |
| 18:01 | <gsnedders> | Still really actively developed. |
| 18:02 | <gsnedders> | Not used by so many things internally to Google, AFAIK, though |
| 18:02 | <gsnedders> | " At Google, it's used in Web Search, Maps, YouTube, Google Plus, Gmail, Docs, Sites, Books, Blogger, Calendar, Picasa Web Albums, and more. " |
| 18:02 | <Hixie_> | no, opera |
| 18:02 | <gsnedders> | Oh, yeah. Now. |
| 18:03 | <bholley> | gsnedders: yuck |
| 18:03 | <bholley> | gsnedders: would Closure get confused if we started including more stack frames? |
| 18:03 | <gsnedders> | But Carakan shipped in 2010, so three years of that bug being current and unfixed |
| 18:03 | <gsnedders> | bholley: In what UA's codepath? |
| 18:04 | <bholley> | gsnedders: well, I'm mostly interested in Gecko |
| 18:04 | <gsnedders> | (Yes, it's horrible that that's even a relevant question.) |
| 18:04 | <gsnedders> | IIRC, Gecko would be fine. |
| 18:05 | <bholley> | gsnedders: who _wouldn't_ be fine, if I dare ask? |
| 18:05 | <gsnedders> | The WebKit codepath, I think. |
| 18:05 | <bholley> | gsnedders: why? |
| 18:05 | <gsnedders> | bholley: Because it does things like length checks. |
| 18:06 | <gsnedders> | In quite bizarre ways. |
| 18:06 | <gsnedders> | (Disclaimer: I haven't looked at this in about a year, so it could've changed. I wouldn't have much hope, though) |
| 18:06 | <gsnedders> | AFAICT, what practically need be done is standardize SpiderMonkey's Error.stack, as that's what is most relied on. |
| 18:07 | <gsnedders> | However much it sucks. :( |
| 18:07 | <bholley> | gsnedders: ok. I'd really like to try including more stack frames |
| 18:07 | <bholley> | gsnedders: I guess we'll see |
| 18:07 | <gsnedders> | bholley: I'd like to try that too. Not overly hopeful, though. :( |
| 18:08 | <gsnedders> | Carakan, FWIW, has both Error.stack (~SpiderMonkey behaviour), and Error.stacktrace (human readable, with more detail) |
| 18:21 | <Domenic_> | bholley: I don't work for Blink, but I hope so. I have heard the Firefox dev tools guys might want to make long stack traces work, and then that could cause competitive pressure like it did for dev tools file blacklisting. |
| 18:22 | <bholley> | Domenic_: aren't you doing Web Components at Google? |
| 18:22 | <Domenic_> | One solution generally might be to give up on standardizing error.stack and try standardizing a more-useful array of tuples (error.stackFames or similar). |
| 18:22 | <bholley> | Domenic_: or are you purely at the spec level? |
| 18:22 | <Domenic_> | bholley: nope, haha. i work for a consultancy. |
| 18:23 | <Domenic_> | i happen to be doing the es6 promises spec, but just in my spare time. |
| 18:23 | <bholley> | oh, you're a different Dominic |
| 18:23 | <bholley> | er |
| 18:23 | <bholley> | yes |
| 18:23 | <bholley> | you are not Dominic |
| 18:23 | <bholley> | (Cooney) |
| 18:23 | <Domenic_> | ah right |
| 18:27 | <gsnedders> | Domenic_: On the other hand Error.stack isn't going away |
| 18:28 | <Domenic_> | gsnedders: yeah. but if there are compat constraints that *prevent* convergence, e.g. ua-sniffing dependent codepaths, can't imagine what to do to fix that... |
| 18:33 | <Ms2ger> | Evangelism |
| 18:42 | <Hixie_> | i hope rniwa is happy with my e-mail |
| 21:20 | <jgraham> | bholley: We should really avoid mested event loops in servo. No good ever came of them |
| 21:20 | <bholley> | jgraham: you mean, design it like the spec does it? |
| 21:21 | <jgraham> | For example |
| 21:21 | <bholley> | jgraham: that requires a lot of help from the JS engine |
| 21:21 | <bholley> | in particualr, being able to pause execution |
| 21:21 | <jgraham> | hmm |
| 21:21 | <bholley> | the spec makes it sound easy, but it's not |
| 21:22 | <bholley> | especially because JS and C++/Rust interleave |
| 21:22 | <bholley> | how do you save all of that state without leaving it on the stack? |
| 21:22 | <jgraham> | Everything not-carakan sucks |
| 21:22 | <bholley> | jgraham: how does carakan do it? |
| 21:23 | jgraham | can't type fast enoihh to have a real conversation; using a phone |
| 21:24 | bholley | would be impressed if carakan could avoid this problem |
| 21:24 | <jgraham> | well opera, even pre carakan could pause the script engine |
| 21:25 | <bholley> | ah, to process events and be responsive, right? |
| 21:26 | <jgraham> | I don't remember if it could run different script whilst pausing one |
| 21:26 | <jgraham> | right |
| 21:27 | <bholley> | jgraham: so how does that work with C++ and JS interleaving? |
| 21:27 | <jgraham> | but I thought other browsers were at least different to gecko here and msybe simpler |
| 21:29 | <jgraham> | bholley: I am the wrong person to ask about the exact implementation |
| 22:26 | <Hixie_> | rniwa: did you see my mail? |
| 22:28 | <Hixie_> | bholley: i don't know how opera did it exactly, but you can envisage a mode where js execution operates entirely separate from the C++ stack, much like how parsing HTML doesn't use the C++ stack, and where any API that might involve spinning the event loop is implemented as two halves, one of which just queues the other. |
| 22:28 | <Hixie_> | bholley: i doubt it would be particularly efficient |
| 22:28 | <Hixie_> | bholley: but it's certainly implementable in theory |
| 22:29 | <bholley> | Hixie_: but how does JS operate separately from the C++ stack? What happens when the calls interleave? |
| 22:29 | <Hixie_> | bholley: you mean like event dispatch? |
| 22:30 | <bholley> | Hixie_: or callbacks |
| 22:30 | <Hixie_> | bholley: you'd just treat that the same as spinning the event loop, essentially. have the C++ API implemented in a completely interruptible way, so that at the point where it would call the JS, it starts that off, queues itself again (with its internal state) as the thing to run once the script is done, then actually returns. |
| 22:31 | <Hixie_> | bholley: (i'm not saying this is a sane way to actually implement a performant UA) |
| 22:31 | <Hixie_> | (or a maintainable one) |
| 22:31 | <Hixie_> | the better way to implement what the spec does would be to use real continuations, in a language that supports those natively. |
| 22:31 | <bholley> | heh |
| 22:31 | <Hixie_> | so that you could shunt the entire stack, C++ and JS together, into a continuation. |
| 22:32 | <bholley> | I don't think rust does |
| 22:32 | <bholley> | heh |
| 22:32 | <Hixie_> | in practice, i assume most UAs just actually nest the event loop, though that has a whole suit of issues. |
| 22:32 | <bholley> | Hixie_: which issues does the spec's approach avoid? |
| 22:33 | <Hixie_> | you never have to worry about whether you have more than one event loop going |
| 22:33 | <Hixie_> | makes it much easier to reason about when things actually run |
| 22:33 | <Hixie_> | also, should it ever be possible for "spin the event loop" conditions to return out of order, you don't end up unable to return to the right caller |
| 22:33 | <Hixie_> | also, you avoid your stack getting out of hand |
| 22:34 | <Hixie_> | and you can never return without it costing anything |
| 22:34 | <Hixie_> | just throw the continuation away |
| 22:34 | <Hixie_> | no need to be able to handle "this is irrelevant, just unwind please" cases |
| 22:36 | <bholley> | Hixie_: I also wanted to talk to you about session history, though maybe this isn't the time |
| 22:36 | <Hixie_> | bholley: there's never a good time for talking about session history :-P |
| 22:36 | <Hixie_> | bholley: might as well try now :-P |
| 22:37 | <Hixie_> | (unless it's not a good time for you) |
| 22:37 | <bholley> | Hixie_: well, I'm concerned that I'm too tired |
| 22:37 | <bholley> | Hixie_: but maybe I'll just try a high-level |
| 22:37 | <Hixie_> | you want to be very awake to talk about session history stuff |
| 22:37 | <Hixie_> | it's part of the whole navigation subsystem, which is probably the most complicated part of the spec |
| 22:37 | <bholley> | Hixie_: that or Location ;-) |
| 22:37 | <Hixie_> | (but don't worry! we've proven it's interoperable, so we're good! just as the HTMLWG!) |
| 22:38 | <rniwa> | Hixie_: yes |
| 22:38 | <rniwa> | Hixie_: thanks! |
| 22:38 | <Hixie_> | bholley: well, the nav parts of Location are part of the same thing, and the security parts of Location are definitely not as complicated, they're far more localised |
| 22:38 | <rniwa> | Hixie_: haven't had a chance to read through hit |
| 22:38 | <Hixie_> | rniwa: right-o |
| 22:38 | <rniwa> | Hixie_: but I think your response makes sense |
| 22:38 | <Hixie_> | rniwa: let me know if i can help further |
| 22:38 | <rniwa> | Hixie_: will read & respond as needed |
| 22:38 | <rniwa> | Hixie_: yeah, thanks! |
| 22:39 | <Hixie_> | rniwa: i did find a couple of errors in the spec walking through it, so thanks for asking, even though my answer was basically just "the spec already says that" :-) |
| 22:40 | <bholley> | Hixie_: so anyway. In Gecko, session history is stored at the top of the BC tree, and is represented as a tree of session history entries, each of which represents a given BC in the tree as it is currently navigated |
| 22:40 | <bholley> | Hixie_: whenever anything navigates, we snapshot/clone the entire tree and add that as an entry |
| 22:41 | <bholley> | Hixie_: IIUC, the spec's model is quite different. Am I correct? |
| 22:42 | <Hixie_> | bholley: i think the spec's model is isomorphic, but it's certainly described very differently |
| 22:43 | <bholley> | Hixie_: in the spec, is a browsing context parented to a document, or parented to another browsing context? |
| 22:43 | <Hixie_> | bholley: neither, precisely |
| 22:44 | <Hixie_> | bholley: nested browsing contexts are, in most cases, parented to an element (<iframe>, <frame>, <object>, and in some edge cases involving SVG, <embed> or <img>), which themselves belong to documents, which belong to browsing contexts. |
| 22:45 | Hixie_ | sprinkles "in most cases" and "roughly speaking" througout that sentence |
| 22:45 | <Hixie_> | throughout |
| 22:47 | <bholley> | Hixie_: do session history entries live on the browsing context? |
| 22:47 | <Hixie_> | bholley: "The sequence of Documents in a browsing context is its session history" |
| 22:48 | <bholley> | Hixie_: so this means that, when the UA decides to GC a document, the relevant session history goes away too? |
| 22:49 | <Hixie_> | bholley: insufficient detail, please elaborate |
| 22:49 | <Hixie_> | bholley: when a document is GC'ed, session history entries relating to frames within that document go away |
| 22:49 | <Hixie_> | bholley: session history entries involving that document itself do not |
| 22:50 | <bholley> | Hixie_: If the session history is just the list of documents, how does that last part work? |
| 22:50 | <bholley> | Hixie_: if the document is GCed, then it's nulled out, right? |
| 22:52 | <Hixie_> | bholley: the entries include more information than just the reference to the Document |
| 22:52 | <Hixie_> | bholley: but yeah, the sentence i pasted does make that unclear |
| 22:52 | <Hixie_> | a few sentences later it says "Each session history entry consists of a URL and optionally a state object, and may in addition have a title, a Document object, form data, a scroll position, and other information associated with it." |
| 22:52 | <bholley> | Hixie_: ok. So a browsing context has a list of entries, which include both URIs and direct document references |
| 22:53 | <Hixie_> | yeah. traversing the history checks if the document is still alive, and if not, brings a new one up |
| 22:54 | <Hixie_> | (filed a bug on making that contradiction less blatent) |
| 22:56 | <bholley> | Hixie_: so, consider this: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2569 |
| 22:56 | <bholley> | Hixie_: (you want rendered view for this one) |
| 22:57 | <Hixie_> | yeah, i was gonna say, live dom viewer with session history, you're a brave man |
| 22:57 | <bholley> | Hixie_: basically, we have an outer frame, P. P begins with an inner frame, C, which gets navigated to C' |
| 22:57 | <bholley> | Hixie_: then, P gets navigated to P' |
| 22:57 | <Hixie_> | yup |
| 22:57 | <Hixie_> | lgtm so far |
| 22:57 | <bholley> | Hixie_: in Gecko, hitting back after the P' navigation gives you a C' subframe |
| 22:58 | <Hixie_> | chrome also |
| 22:58 | <Hixie_> | which we explain via the bfcache |
| 22:58 | <bholley> | Hixie_: but in the spec, it depends on GC |
| 22:58 | <Hixie_> | yeah, it's true that if we assume the doc got GC'ed (which i guess it did in chrome), the spec doesn't explain this |
| 22:58 | <Hixie_> | having said that, i'd argue this behaviour if the doc _did_ get GC'ed is rather dubious |
| 22:59 | <Hixie_> | because you don't really have a sane way to know how to reconstruct the right state |
| 22:59 | <bholley> | Hixie_: well, Gecko does a whole lot of work to do so |
| 22:59 | <Hixie_> | i mean, how do you know which iframe to use? |
| 22:59 | <Hixie_> | it's all one big heuristic |
| 22:59 | <bholley> | Hixie_: yep |
| 22:59 | Hixie_ | votes to kill the heuristic |
| 23:00 | <bholley> | Hixie_: me too, but doing so is not necessarily web compatible |
| 23:00 | <bholley> | Hixie_: I mean, implementing the spec is like, 10 times easier than implementing it Gecko-style |
| 23:00 | <Hixie_> | well, the heuristic isn't either, especially in the case of web apps |
| 23:00 | <Hixie_> | web compatible, that is |
| 23:00 | <bholley> | Hixie_: the heuristic is totally web-compatible |
| 23:00 | <Hixie_> | i think it's reasonable to do it in the case of the page being static |
| 23:01 | <bholley> | Hixie_: Gecko does it. Chrome mostly kinda sorta tries to copy it |
| 23:01 | <Hixie_> | that heuristic has actually broken my pages |
| 23:01 | <Hixie_> | i've had to do all kinds of workarounds to stop it |
| 23:01 | <bholley> | Hixie_: sure. But that's your problem as a web author |
| 23:01 | <Hixie_> | i care about web authors :-) |
| 23:01 | <bholley> | Hixie_: I know. But I'm saying that you're conflating "developer-friendly" with "web-compatible" |
| 23:01 | <Hixie_> | well fair enough |
| 23:01 | <bholley> | Hixie_: they're two very different concepts |
| 23:02 | <Hixie_> | though i'm sure this breaks web apps that use iframes internally but haven't been tested with the back button |
| 23:02 | <Hixie_> | anyway |
| 23:02 | <bholley> | Hixie_: yeah, sure |
| 23:02 | <Hixie_> | i'm happy to spec this if that's where we're going with this |
| 23:02 | <bholley> | Hixie_: so, I'm all in favor of the spec |
| 23:02 | <Hixie_> | but i need a detailed precise description of the heuristic |
| 23:02 | <bholley> | Hixie_: and I want to try to implement the spec in servo |
| 23:02 | <bholley> | Hixie_: but smaug is adamant that Gecko's model is necessary to avoid breaking the web |
| 23:03 | <Hixie_> | bholley: in the case of non-static pages? |
| 23:03 | <bholley> | Hixie_: he didn't go into detail. But it sounds like this whole situation is very touchy |
| 23:03 | <Hixie_> | this is certainly a third rail issue |
| 23:04 | <bholley> | Hixie_: so anyway. Implementing the spec is very straightforward, so that's what I'm going to do in servo |
| 23:04 | <Hixie_> | basically my view is that in all the cases where you can't tell from script that the docs got GC'ed, i'm all in favour of the browsers pretending the docs weren't GC'ed and bringing everything back. but in the case where there's a way to tell whether or not the doc got GC'ed, e.g. going back is going to rerun some script that creates iframes or whatnot, then the spec model is the only sane option. imho. |
| 23:05 | <bholley> | (also, onpageshow) |
| 23:06 | <Hixie_> | oh pretty much any script |
| 23:07 | <bholley> | so anyway. The spec might need to change, but at the moment it's the simplest option to implement, and I only want to implement the Gecko setup if it becomes clear that the spec model breaks the web and that servo is going to be shippable modulo this issue |
| 23:08 | <Hixie_> | k |
| 23:08 | <Hixie_> | sounds good |
| 23:08 | <Hixie_> | if you do decide the spec needs to change, i need a description of what it should say |
| 23:08 | <Hixie_> | because i'm at a loss as to how to spec that heuristic |
| 23:08 | bholley | doesn't look forward to it |