| 00:59 | <MikeSmith> | Domenic: thanks for the heads-up, banned |
| 01:18 | <kochi> | MikeSmith: thanks, it seems my request was accepted. |
| 01:35 | <MikeSmith> | kochi: super |
| 09:07 | <jgraham> | Anyone know what the pref name is in Chrome to allow popups? (i.e. the one that gets written to the Preferences file) |
| 09:41 | <jgraham> | (found it) |
| 12:32 | <mnot1> | Sitting in the IETF Security Area meeting, where an NSA person is presenting about a WebSockets vulnerability |
| 12:32 | <mnot1> | https://www.ietf.org/proceedings/96/slides/slides-96-saag-1.pdf |
| 12:32 | <mnot1> | basically, timing attack against the handshake |
| 12:34 | <mnot1> | annevk: put the mitigation in fetch (if it pans out)? |
| 12:34 | <annevk> | mnot1: port blocking is part of Fetch |
| 12:35 | <mnot1> | he wants to delay the handshake so you can't tell between a listening and non-listening port |
| 12:35 | <annevk> | mnot1: oh I see |
| 12:35 | <mnot1> | looking for his draft... |
| 12:35 | <annevk> | mnot1: since WebSocket gets its own connection there's a little more room for nastyness? |
| 12:36 | <mnot1> | y |
| 12:36 | <annevk> | Because in principle you can do this with <img> |
| 12:37 | <mnot1> | webworkers + websockets makes it faster… or could you do webworkers + <img>? hmm |
| 12:38 | <annevk> | can't, can do importScripts() or fetch() |
| 12:40 | <nox> | https://github.com/w3c/IndexedDB/issues/83 Does this make sense to anyone? |
| 12:41 | <annevk> | nox: does |
| 12:45 | <smaug____> | is registerElement still defined in some spec? |
| 12:45 | <smaug____> | or was that removed? |
| 12:46 | <annevk> | smaug____: renamed to customElements.define() |
| 12:46 | <annevk> | smaug____: HTML Standard |
| 12:46 | <smaug____> | HTML? |
| 12:46 | <botie> | HTML is, like, different, only browsers use HTML for the most part |
| 12:47 | <smaug____> | not CustomElements spec which has interface CustomElementsRegistry |
| 12:47 | <annevk> | smaug____: CustomElements spec is a copy that is typically out-of-date as I understand it |
| 12:47 | <smaug____> | uh |
| 12:47 | <smaug____> | ok, now I've been looking at wrong spec |
| 12:48 | <smaug____> | why CustomElements are in HTML spec? |
| 12:48 | <smaug____> | wouldn't DOM be more natural? |
| 12:48 | <smaug____> | though, doesn't matter much |
| 12:48 | <annevk> | smaug____: because it's custom HTML elements mostly and they integrate with the HTML parser and such |
| 12:48 | <annevk> | smaug____: there's a couple of hooks in DOM too to queue the callbacks |
| 12:48 | <annevk> | smaug____: and to define the new state for elements |
| 12:49 | <annevk> | smaug____: and DOM defines createElement() still of course |
| 12:49 | <annevk> | smaug____: I think we mostly went with HTML since you can only subclass HTMLElement |
| 12:49 | <annevk> | (and the HTML parser) |
| 12:49 | <smaug____> | I see |
| 12:50 | <smaug____> | hmm, I wonder why Element can't be subclassed |
| 13:00 | <annevk> | smaug____: I have forgotten, probably because you could never serialize it and therefore it would not be that useful |
| 13:11 | <annevk> | smaug____: so yeah, https://w3c.github.io/webcomponents/spec/custom/ is a month out-of-date |
| 13:11 | <smaug____> | ok, thanks |
| 13:11 | <annevk> | smaug____: I landed changes for custom elements three hours ago in HTML |
| 13:11 | <smaug____> | https://w3c.github.io/webcomponents/spec/custom/ could perhaps have a warning it being out-of-date most of the time |
| 13:11 | <smaug____> | (no one reads the Abstract ;) ) |
| 13:13 | <annevk> | Domenic: ^^ |
| 13:35 | <nox> | annevk: Thanks btw. :) |
| 13:36 | <nox> | annevk: I died inside when i found this problem. |
| 13:36 | <annevk> | nox: standards being ignorant about threads and having issues with parallelism is fairly common still |
| 13:37 | <annevk> | nox: we only really started thinking in terms of event loops after Hixie wrote one down |
| 13:37 | <nox> | annevk: I know, but it's the first time it happens in a spec I'm actually implementing. :P |
| 13:37 | <annevk> | hehe |
| 13:47 | <wanderview> | I wish spec's were written in markdown. It would be a lot easier to review changes |
| 13:47 | <nox> | And a lot harder to edit IMO. |
| 13:48 | <wanderview> | or at least fricking wrap lines to a reasonable width |
| 13:51 | <annevk> | smaug____: does it seem reasonable to you to fix one part of <iframe>'s problems first https://github.com/w3c/webcomponents/issues/145#issuecomment-234258706? |
| 13:51 | <annevk> | wanderview: 100 columns is not reasonable? |
| 13:51 | <annevk> | wanderview: it might be time to get a bigger monitor |
| 13:51 | <wanderview> | annevk: https://github.com/slightlyoff/ServiceWorker/commit/5c0ecaeb423d04df7429bfaa2e5fbde9e42038e1 |
| 13:52 | <annevk> | wanderview: ooh, but you left that comment on a change to HTML |
| 13:52 | <wanderview> | line 714 of that commit is a hell of lot bigger than 100 chars |
| 13:52 | <annevk> | HTML commits don't have that |
| 13:52 | <wanderview> | annevk: how can I interpret the change to html without reviewing that other commit it depends on? |
| 13:52 | <annevk> | Sure, your comment was just not very specific |
| 13:59 | <annevk> | wanderview: note that the client message queue bit landed in SW so you could read it in the spec |
| 14:29 | <mounir> | annevk: xref's html.py takes ages and ends up with exceptions, it is worth battling with it? |
| 14:36 | <annevk> | mounir: exceptions are basically terms that need to be removed, but you can leave a comment and I can take care of it I suppose |
| 15:10 | <mounir> | annevk: I've removed them |
| 15:10 | <mounir> | annevk: updated the 3 CLs -- whenever you have time ;) |
| 15:10 | <annevk> | mounir: ta, maybe tonight, but might be tomorrow morning |
| 17:50 | <annevk> | mounir: landed whatwg/fullscreen and whatwg/xref |
| 17:50 | <annevk> | mounir: thanks a lot for doing all of the work required, that's great |
| 17:52 | <annevk> | mounir: it seems I can even merge the screen orientation PR, but I'll leave that up to you |
| 18:27 | <smaug____> | does anyone happen to know when blink dispatches click |
| 18:27 | <smaug____> | after mousedown/up |
| 18:28 | <smaug____> | oh oh, it has some very specific hack for <button>s |
| 19:07 | <Domenic> | ;_; |
| 19:07 | <Domenic> | Why all the sudden UI event infrastructure investigations, smaug____? I mean, it's good for improving the spec and such, but why would you do this to yourself. |
| 19:13 | <smaug____> | Domenic: just fixing a bug |
| 19:13 | <smaug____> | well, not a but |
| 19:13 | <smaug____> | <button> handling in Gecko is per HTML4 |
| 19:13 | <smaug____> | s/but/bug/ |
| 19:13 | <smaug____> | but since other browsers have other behavior, need to change the behavior |
| 19:13 | <Domenic> | I see |
| 19:13 | <Domenic> | I wonder what HTML4 said about buttons... /me goes to look |
| 19:14 | <Domenic> | So far it's not clear that they can be clicked https://www.w3.org/TR/html4/interact/forms.html#h-17.5 |
| 19:14 | <smaug____> | <button> in HTML4 is just a way to have more complicated rendering for the button |
| 19:14 | <smaug____> | or that is at least one interpretation |
| 19:15 | <smaug____> | so in Gecko events inside <button> go always to the <button> |
| 19:15 | <smaug____> | but now, I'm trying to understand how click even works in blink |
| 19:15 | <Domenic> | We got a "when activated" in https://www.w3.org/TR/html4/interact/forms.html#submit-button which seems to acknowledge the existence of clicking |
| 19:16 | <smaug____> | I thought it click would be dispatched to common ancestor of mousedown and mouseup |
| 19:16 | <smaug____> | in blink |
| 19:16 | <smaug____> | but apparently it is very different |
| 19:16 | <smaug____> | in some cases common ancestor |
| 19:16 | <smaug____> | in other cases... it doesn't happen at all |
| 19:16 | <Domenic> | rbyers might be able to help |
| 19:19 | <smaug____> | yeah, I tried to ping him |
| 19:28 | <smaug____> | ok, found the code |
| 19:52 | <rbyers> | smaug____: Sorry for the delay, I'm on vacation. I thought it was usually common ancestor - at least that's the code I know. |
| 19:53 | <smaug____> | rbyers: it is not that. there is also something about interactivecontent or such |
| 19:53 | <rbyers> | Dtapuska@ and Mustaq@ probably know more. You could ask on input-dev⊙co or file a bug for anything you see that's not to spec. |
| 19:55 | <rbyers> | Input team considers any spec / blink mismatch to be a chromium bug, even if the right fix ends up being to change the spec... |
| 19:55 | <smaug____> | rbyers: I found the relevant code in blink. I was just surprised since it has been discussed before the click should happen on common ancestor |
| 19:56 | <smaug____> | but there are cases when click doesn't happen at all in blink after mousedown/up |
| 19:56 | <smaug____> | this is per element basis |
| 19:56 | <smaug____> | form elements, <a> and some others |
| 19:56 | <smaug____> | they all affect to click dispatching in blink apparently |
| 19:57 | <rbyers> | Hmm. If its not too breaking, we can probably get rid of any such special cases. IIRC the click we fire for touch had no such special cases. |
| 19:58 | <rbyers> | So the inconsistency is weird, probably just another sign of mouse code being so crusty and unmaintained for so long. |
| 19:59 | <rbyers> | Then again, web compat in this area is super brittle - every time we try to clean something up we are surprised by unexpected breakage. Still, we're not afraid to try.. |
| 20:01 | <smaug____> | rbyers: there is some comment in the code about IEism, so it might be quite breaking change |
| 20:01 | <smaug____> | I should look at the blame to see when it was added |
| 20:01 | <smaug____> | rbyers: go back to your vacation! |
| 20:02 | <rbyers> | Best test is probably Edge. If Edge doesn't do that, we can almost certainly change. |
| 20:02 | <rbyers> | Thanks, TTYL :-) |