| 04:02 | <GPHemsley> | Domenic: Chrome seems to implement the onshow event? |
| 04:02 | <Domenic> | GPHemsley: check canary |
| 04:03 | <Domenic> | It was left in for like one release longer than the context menu code |
| 04:03 | <GPHemsley> | oh, oops, didn't realize I was running stock |
| 10:31 | <molsson> | I created a bare bones polyfill for AbortController+fetch, PRs welcome if I screwed it up somehow --> https://git.io/v7Loc |
| 10:40 | <annevk> | molsson: FWIW, the idea behind AbortController is also that it spreads to all kinds of APIs |
| 10:41 | <annevk> | molsson: so it'll be either that or the TC39 proposal that will eventually be used |
| 10:42 | <molsson> | if the TC39 proposal takes hold, will the DOM implement that as well then? |
| 10:44 | <annevk> | molsson: yeah, I'd expect some changes in that case, seems a bit unlikely given how long we've waited on TC39, but who knows, should know more at the end of this week |
| 10:45 | <molsson> | right |
| 10:49 | <JakeA> | It'd need to be clonable across workers for instance, which the doc doesn't seem to cover |
| 10:50 | <JakeA> | Seems like it's a long time away in TC39 terms |
| 11:10 | <kochi> | annevk: thanks for the heads-up (re https://www.w3.org/Bugs/Public/show_bug.cgi?id=24379) |
| 13:45 | <wanderview> | annevk: yes, lets not wait on tc39 for canceling again |
| 14:22 | <wanderview> | Domenic: in spec language, does resolving or rejecting a promise implicitly queue a task to the correct target realm thread? |
| 14:23 | <wanderview> | if you are in a parallel section, etc |
| 14:29 | <annevk> | wanderview: in theory, but it's very poorly defined since it doesn't define the task source and such |
| 14:29 | <annevk> | wanderview: there's some language to that effect in the promises guide which should be uplifted to HTML/IDL and then appropriately refactored to also take a source into account |
| 14:30 | <wanderview> | annevk: ok, it might be confusing since accessing other js objects in parallel sections I guess is bad |
| 14:30 | <annevk> | wanderview: yeah, I don't think it's good practice |
| 14:31 | <annevk> | wanderview: I think folks should always queue a task and resolve/reject from that task |
| 14:31 | <annevk> | wanderview: then it's also clear you need to define a task source |
| 15:33 | <wanderview> | rbyers: I know its out of your hands, but its kind of frustrating to do spec work to make stuff feature detectable and then have one of the spec participants still use UA sniffing instead... in reference to https://bugzilla.mozilla.org/show_bug.cgi?id=1128959#c140 |
| 15:41 | <wanderview> | rbyers: also, I'm curious how the site can't support firefox at all without streams API |
| 16:06 | <rbyers> | wanderview: I totally understand, I'm frustrated to. dknox and I are increasing investments to try to improve things here within Google. |
| 16:09 | <rbyers> | ... related: you're not too far from Toronto IIRC, right? |
| 16:09 | <rbyers> | ... Mike Taylor is bringing a couple Mozilla folks to Google Waterloo in a couple weeks to do a web compat hackathon, you might be interested in joining: https://docs.google.com/document/d/1FIUk5Y5_VmZ8rqHEsFEoXaysJUCRzf3RbvcyuYpim9c/edit |
| 16:15 | <rbyers> | And FWIW it's probably the case that the site in question _could_ support Firefox without streams, it's high on their list of reasons why supporting Firefox with high quality is too expensive to currently be worth it for them. I see it as part of my job to help eliminate all such reasons :-) |
| 16:26 | <wanderview> | rbyers: is this streams within service workers? |
| 16:27 | <wanderview> | rbyers: waterloo is about a 3 hour drive (depending on the bridge)... I could run it by my wife |
| 16:28 | <rbyers> | wanderview: I don't think so, just fetch API. I don't actually know details myself (just trying to relay discussions I'm following). |
| 16:29 | <rbyers> | ... Your call on the compat hackathon. I'm convinced we can make the web work better for everyone through more Mozilla/Google collaboration (eg. shifting more of the burden from Gecko to chromium engineers as we're working to do with our web-platform-test requirements). |
| 16:32 | <rbyers> | ... But I don't know concretely what things will have the biggest impact. |
| 17:49 | <wanderview> | rbyers: fwiw, I am doubtful streams will hit release channel until september or november... we're close, but have some thorny details to iron out |
| 17:50 | <wanderview> | rbyers: although we will probably have a configuration someone could use to test with before then... install nightly and flip a pref... if that would allow your web devs to enable FF UA with feature detection |
| 18:09 | <rbyers> | wanderview: Thanks. I'll mention that to them. |
| 18:11 | <rbyers> | wanderview: Are there specific spec/test quality issues that you wish Google folks were more engaged in addressing? |
| 19:15 | <wanderview> | rbyers: bz might have more answers to that question |
| 20:13 | <wanderview> | rbyers: the work on WPT tests recently has been very helpful... and fixing problems those have revealed... so that is good |
| 20:14 | <wanderview> | rbyers: I think it would be great if blink implementors and reviewers were more keyed into when the spec is missing information... if you are implementing something and the spec doesn't actually say what to do, then please file an issue... I feel like we uncover this kind of thing all the time as the second implementor |
| 20:48 | <rbyers> | wanderview: Thanks. Yeah I don't know how to systematize and scale more spec-conformance diligence during implementation. We're trying for sure, but I'm determined to come up with something scalable that relies more on tooling and infrastructure and less on individual heroics. Making WPT first-class in our engineering processes is our primary strategy (glad to hear you're feeling the improvements) but it's definitely |
| 20:48 | <rbyers> | not enough on it's own... |
| 20:50 | <wanderview> | rbyers: IMO, the code review process is the easiest place to inject this sort of thing... but I guess I don't know what that looks like in blink |
| 21:21 | <Mek> | I find it pretty hard when reviewing somebodies code to figure out how hard to push back on the "the spec you're implementing doesn't seem to actually describe any of the behavior you're implementing in enough detail to figure out if the code you wrote matches the spec" |
| 21:22 | <Mek> | ultimately it's not (just) the code author's fault that the spec they're implementing isn't anywhere near a state where it is implementable, and I can see how trying to implement something can be valuable in actually figuring out these gaps in the specs |
| 21:22 | <Mek> | so I'm often not sure what the right balance is between "fix the spec before you land this code" and "as long as the spec and implementation match before shipping, it's probably okay to land this" |
| 21:24 | <wanderview> | Mek: its important to file a spec issue and note what your internal decision for now is... the spec doesn't have to block moving forward, but filing a spec allows it to get visibility |
| 21:25 | <wanderview> | IMO, anyway |
| 21:25 | <wanderview> | I often write review comments like "write a spec issue, link to it here in a comment", etc |
| 21:25 | <Mek> | yeah, that's what I generally end up doing as well (or filing some spec issues myself...) |
| 21:25 | <Mek> | and I actually came here to rant and wonder what it means when a spec says "When X happens the user agent MUST run the Foo algorithm. The exact defails of the Foo algorithm are left to implementers." How can running a completely unspecified algorithm be a MUST requirement... |
| 21:26 | <wanderview> | pretty sure that means to wipe the hard drive |
| 21:27 | <gsnedders> | well, you must run an undefined algorithm |
| 21:27 | <gsnedders> | and we can test that you run an unspecified algorthim by observing that you do… something |
| 21:27 | <wanderview> | undefined is not a function |
| 21:27 | <gsnedders> | Including crashing, I guess. An algorithm could just be the ud2 instruction, after all. |