| 05:09 | <annevk> | Domenic: wow, that is so cool |
| 05:20 | <annevk> | zcorpan: I think Chrome might support it outside the parser |
| 07:11 | <MikeSmith> | FYI http://csswg-test.org/ exists now |
| 07:11 | <MikeSmith> | for people who like such things |
| 07:12 | <MikeSmith> | serves tests from https://github.com/w3c/csswg-test/ using wptserve in the same manner as https://w3c-test.org/ does for https://github.com/w3c/web-platform-tests/ |
| 07:14 | <MikeSmith> | and going forward PR branches for new https://github.com/w3c/csswg-test PRs will show up in http://csswg-test.org/submissions/ |
| 07:15 | <MikeSmith> | if you notice any problems tell gsnedders because he is the owner :) |
| 07:16 | <MikeSmith> | and to be clear as I understand at least this is a temporary thing until such as the grand merge of the CSS tests into WPT finally happens |
| 07:20 | <annevk> | mkwst: so Referrer-Policy doesn't use JSON values afaict |
| 07:20 | <mkwst> | annevk: Hrm? The header? |
| 07:20 | <annevk> | mkwst: per ABNF accepting something like "origin" as value would be broken |
| 07:21 | <annevk> | mkwst: yeah |
| 07:21 | <mkwst> | Hrm. That's not what I thought they were doing. |
| 07:21 | <annevk> | mkwst: perhaps folks mistake "x" for some kind of quoted string production (which also allows JSON-incompatible values so don't use that either) |
| 07:22 | <annevk> | mkwst: so maybe the impl is correct, but the specification is definitely wrong |
| 07:22 | <mkwst> | I thought they agreed with the notion that quoting things would be forward compatible with a more robust structure in the future. |
| 07:22 | <mkwst> | The examples in the spec are also unquoted. Hrm. |
| 07:22 | <annevk> | mkwst: and if the impl is correct and the specification is wrong, then the specification for <meta name=referrer> is also wrong |
| 07:22 | <mkwst> | I'll ping Emily when she wakes up. :) |
| 07:22 | <annevk> | mkwst: since <meta name=referrer> is defined in terms of the header... |
| 07:23 | <annevk> | (I'm not sure why we're doing that) |
| 07:23 | <mkwst> | No, looks like Chrome's (experimental) implementation doesn't have quotes. |
| 07:28 | <mkwst> | Filed https://github.com/w3c/webappsec-referrer-policy/issues/65 |
| 07:32 | <annevk> | Not sure I agree with "we seem to be going" but shrug |
| 09:11 | <rniwa> | annevk: yt? |
| 09:12 | <rniwa> | Domenic: yt? |
| 09:13 | <annevk> | rniwa: yup |
| 09:13 | <rniwa> | annevk: hi |
| 09:14 | <rniwa> | annevk: so I was looking at document.open with respect to custom elements |
| 09:14 | <rniwa> | annevk: and I realized that we don't create new window object at all |
| 09:14 | <rniwa> | annevk: neither does Chrome |
| 09:14 | <rniwa> | annevk: so I'm not sure the whole section about Call the JavaScript InitializeHostDefinedRealm() |
| 09:14 | <rniwa> | and then replacing all singleton objects is needed at all for compat |
| 09:14 | <annevk> | interesting |
| 09:15 | <rniwa> | annevk: https://trac.webkit.org/browser/trunk/Source/WebCore/dom/Document.cpp#L2557 |
| 09:15 | <annevk> | so what happens instead? |
| 09:15 | <rniwa> | annevk: we basically only setup the parser |
| 09:15 | <rniwa> | annevk: and don't touch global object at all |
| 09:15 | <rniwa> | annevk: we just go ahead & use the same global object |
| 09:15 | <annevk> | rniwa: that's worth filing a bug on |
| 09:15 | <rniwa> | annevk: in fact, it's possible that some web content outside might be dependent on this behavior |
| 09:16 | <annevk> | I don't really recall any discussion about that, but it's mostly been Hixie territory |
| 09:16 | <rniwa> | annevk: because all global variables, etc... would go away. |
| 09:17 | <annevk> | that looks so much simpler than the spec |
| 09:18 | <rniwa> | annevk: it is! |
| 09:18 | <rniwa> | annevk: given that we've been shipping it this way for such a long time, it's hard to believe it's not Web compatible |
| 09:18 | <annevk> | rniwa: why is implicitOpen() its own function? |
| 09:18 | <rniwa> | I mean... I would be really surprised if it weren't |
| 09:18 | <annevk> | rniwa: compatible enough anyway |
| 09:18 | <rniwa> | annevk: yeah |
| 09:18 | <rniwa> | annevk: worse yet, it might be that some content depends on our behavior |
| 09:19 | <rniwa> | as in... it's easier to depend on your global being the same than it changing after document.open |
| 09:20 | <annevk> | Yeah, it's such a massive simplification too |
| 09:21 | <annevk> | This means that a Document is only ever associated with one Window |
| 09:21 | <rniwa> | annevk: right, which is much saner model to deal with |
| 09:21 | <annevk> | Uhuh |
| 09:21 | <annevk> | Please file an issue? I'm curious what bz has to say about it |
| 09:24 | <rniwa> | annevk: there's some interesting comment at: https://trac.webkit.org/browser/trunk/Source/WebCore/bindings/js/JSHTMLDocumentCustom.cpp#L171 |
| 09:24 | <rniwa> | but it's probably still a lot simpler than whatever we're doing in the current spec. |
| 09:27 | <rniwa> | annevk: https://github.com/whatwg/html/issues/1698 |
| 09:27 | <annevk> | ta |
| 09:27 | <rniwa> | annevk: changing the spec would make my life much easier |
| 09:28 | <rniwa> | there's no way I'm gonna add this crazy feature just to support an edge case in custom elements LOL |
| 09:28 | <rniwa> | so it's not like it's gonna make my life any harder |
| 09:28 | <rniwa> | but... |
| 09:29 | <rniwa> | not having to worry about this case in the future would be nice. |
| 09:29 | <annevk> | rniwa: yeah, I wonder what that JSHTMLDocument thing is about |
| 09:29 | <annevk> | rniwa: that's a little harder to read |
| 09:30 | <annevk> | rniwa: does it create a new wrapper around the global? |
| 09:31 | <rniwa> | annevk: it was added by https://trac.webkit.org/changeset/34506 |
| 09:31 | <rniwa> | annevk: no, I think it's about changing the security origin |
| 09:32 | <rniwa> | annevk: so like... we reset the security origin to that of the script which invoked doucment.open/write |
| 09:32 | <rniwa> | annevk: even if its security origin initially belonged to some other window of the same origin |
| 09:32 | <annevk> | rniwa: ah okay, in the spec that might be a side effect of changing the URL of the document |
| 09:33 | <annevk> | (spec is not great...) |
| 09:33 | <rniwa> | annevk: yeah, I'm not too familiar with this area of the code to confirm that but that sounds right |
| 09:34 | <rniwa> | anyway, I hope we can change it to WebKit/Blink way |
| 09:34 | <annevk> | same |
| 09:36 | <rniwa> | annevk: somewhat relatedly, I found a hilarious bug in WebKit & Blink: https://bugs.webkit.org/show_bug.cgi?id=160952 |
| 09:36 | <rniwa> | annevk: because we create wrappers lazily LOL |
| 09:37 | rniwa | should somehow let Blink guys know about this bug |
| 09:37 | <annevk> | rniwa: see also the discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 |
| 09:38 | <annevk> | rniwa: WebKit can change the wrapper from one global to another due to GC |
| 09:38 | <annevk> | rniwa: which is rather weird |
| 09:38 | <rniwa> | annevk: I think we've fixed that |
| 09:39 | <annevk> | ah |
| 09:39 | <rniwa> | annevk: so I think this is one the last ways by which we can screw things up |
| 09:39 | <rniwa> | annevk: although... I was recently checking some stats on how often nodes get adopted |
| 09:39 | <annevk> | rniwa: do you end up just leaking the global or do you do the Gecko thing where you change the [[Prototype]]? |
| 09:39 | <rniwa> | and the answer was basically that almost never |
| 09:39 | <annevk> | huh |
| 09:40 | <rniwa> | annevk: no, we just keep the original global |
| 09:40 | <annevk> | Bobby claimed something about 2.5 globals being leaked on average based on his stats |
| 09:40 | <annevk> | something is wrong |
| 09:40 | <zcorpan> | annevk: in a search I only see it used by HTMLTreeBuilder.cpp and HTMLElement.cpp (by innerText), so i suppose it's fine once innerText is fixed to not throw |
| 09:40 | <zcorpan> | imageTag that is |
| 09:41 | <rniwa> | annevk: that's strange indeed |
| 09:41 | <annevk> | zcorpan: oh, maybe part of it already got fixed when I noticed the first time |
| 09:41 | <rniwa> | annevk: Gmail which had the highest rate of adoption adopted 1299 nodes out of 19200 nodes for example |
| 09:42 | <rniwa> | annevk: the next highest one was CNN, presumably some ads network code, which adopted 40 out of 59200 nodes |
| 09:42 | <rniwa> | annevk: no other websites I looked at adopted any node. |
| 09:42 | <annevk> | zcorpan: seems that Edge still returns an HTMLImageElement for document.createElement("image") |
| 09:43 | <rniwa> | annevk: my research wasn't extensive but it seems like adopting node is not a common occurrence these days. |
| 09:43 | <annevk> | rniwa: I guess if Gmail does adoption and CNN and they don't clean up you could have leaks there |
| 09:43 | <rniwa> | annevk: they totally can. |
| 09:43 | <annevk> | rniwa: which would be avoided by swizzling the prototype |
| 09:44 | <rniwa> | annevk: true |
| 09:44 | <annevk> | Gmail doing it would definitely explain most users seeing leaks |
| 09:44 | <annevk> | (well, they would see leaks if we didn't swizzle) |
| 09:44 | <rniwa> | annevk: yeah, especially it's a pinned tab or something |
| 09:45 | <rniwa> | annevk: although given WebKit/Blink get away with it, I'd be surprised if they were leaking every document |
| 09:45 | <zcorpan> | annevk: ok. no test for it in wpt AFAICT. i can make one and file an issue |
| 09:45 | <annevk> | rniwa: yeah, WebKit/Blink not bothering is a rather strong argument for not complicating the standard |
| 09:46 | <annevk> | zcorpan: \o/ |
| 09:46 | annevk | goes to drink some tea |
| 09:47 | <zcorpan> | i just had a cup of first cup of tea this year i believe, incidentally |
| 09:47 | <zcorpan> | s/a cup of/my/ |
| 09:48 | <zcorpan> | or at least first in several months |
| 10:03 | <zcorpan> | oh it seems to be tested by html/semantics/interfaces.html |
| 10:32 | <zcorpan> | (filed https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8545675/ ) |
| 11:40 | <annevk> | mkwst: would still appreciate a comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=25529 about the CSP thing |
| 11:40 | <annevk> | mkwst: in particular whether it should maybe run when an element is cloned |
| 11:41 | <annevk> | mkwst: or otherwise if we really want to avoid that, we should figure out a way to make that happen in DOM |
| 11:54 | <zcorpan> | first time since vacation: No new notifications. |
| 11:56 | <zcorpan> | but now i have a few dozen open tabs instead :-) |
| 11:57 | <Ms2ger> | Now, to move the dozen tabs to a todo list |
| 11:58 | <jgraham> | And the todo list to the bin? |
| 12:23 | <zcorpan> | one has roundabout ways to mark all as read |
| 12:36 | <annevk> | smaug____: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28097 maybe something you can help with? I'm still a bit lost |
| 12:36 | <annevk> | smaug____: that is, range algorithms continue to confuse me at times |
| 12:36 | <annevk> | (ayg wrote most/all of that) |
| 12:39 | <smaug____> | in middle of something else |
| 12:39 | smaug____ | would need to read the old Range spec |
| 12:42 | <annevk> | smaug____: the old Range spec has no notion of a DocumentFragment potentially having a host |
| 12:42 | <smaug____> | ah, right |
| 12:42 | <smaug____> | this was about 'host* |
| 12:43 | <smaug____> | yeah, sorry, my mind is in memory management and trying to add hacks to fix leaks which web pages like twitter cause |
| 12:44 | <annevk> | hehe |
| 12:44 | <annevk> | I can bother you some other time |
| 12:52 | <smaug____> | FWIW, iframes in twitter add event listener to the window.parent and then the iframe is removed from dom |
| 12:52 | <smaug____> | and event listener isn't used for anything |
| 12:52 | <smaug____> | but parent keeps the event listener and the global related to it alive |
| 12:55 | <smaug____> | this is as bad leak as what Google reader had |
| 12:55 | <smaug____> | though, I think we can optimize this better |
| 12:57 | <annevk> | wow |
| 12:57 | <annevk> | multiple globals, not even once |
| 15:39 | <tobie> | TabAtkins: what's the magic incantation to have syntax highlighting of IDL without the auto-linking stuff and without making the code an example? |
| 15:40 | <tobie> | TabAtkins: data-no-idl doesn't seem to be what I'm looking for. |
| 15:51 | <tobie> | TabAtkins: follow-up question: the WebIDL spec wants to be able to highlight parts of the IDL. The WebIDL parser removes any inline element within the code blocks. What's my option, here? |
| 16:09 | <smaug____> | Domenic: do you happen to know what kind of memory leak hunting blink devs are doing |
| 16:09 | <smaug____> | I mean cases where pages are leaking |
| 16:09 | <smaug____> | (browser engine leaks are different things. So, not talking about CustomEvent or such which still leak in blink, IIRC) |
| 16:25 | <tobie> | TabAtkins: summarized my current issue here: https://github.com/tobie/webidl/issues/27#issuecomment-241064566 |
| 16:26 | <Domenic> | smaug____: I don't really know, sorry. |
| 17:44 | <TabAtkins> | mkwst: That's no longer a behavior of Bikeshed, but is still used by Shepherd for non-Bikeshed documents. To override it, give a data-lt. - that wins over use of title in the spider. |
| 17:45 | <TabAtkins> | zcorpan: Given the number of specs still on Anolis (not many), and the amount of non-trivial work to do to make the spec reasonably idiomatic Bikeshed, I'm not really willing to put effort in. That time would be better spent just converting the remaining specs by hand. |
| 17:51 | <Domenic> | I think we've seen by-hand fail pretty badly so far... I wouldn't be comfortable with it going forward. |
| 18:16 | <tobie> | I wonder how much of the JS pipeline I wrote could be refurbished to help with a generic Anolis -> Bikeshed conversion tool. |
| 18:18 | <tobie> | And I wonder how much XSLT one would have to write to turn Anolis into something that pipeline could handle. |
| 21:28 | <smaug____> | does anyone have a gut feeling whether using eventtarget.onfoo manually is happening commonly. I mean something like window.onclick(new MouseEvent("click")); |
| 21:29 | <smaug____> | (and not via dispatchEvent) |
| 21:34 | <caitp> | smaug____: I wouldn't be surprised if unit tests relied on it a lot |
| 21:34 | <smaug____> | true |
| 21:34 | <smaug____> | I'm thinking about the case with another global sets onfoo |
| 21:34 | <smaug____> | and then that global is "destroyed" |
| 21:35 | <smaug____> | like, iframe's contentWindow setting onfoo in parent |
| 22:03 | <Domenic> | wait what |
| 22:03 | <Domenic> | you can do that |
| 22:03 | <Domenic> | oh i see |
| 22:29 | <tobie> | TabAtkins: any idea why the following would fatal Bikeshed's IDL parser: |
| 22:29 | <tobie> | https://www.irccloud.com/pastebin/b1ZenycN/ |
| 22:31 | <TabAtkins> | tobie: It doesn't. |
| 22:33 | <tobie> | TabAtkins: !? |
| 22:34 | <tobie> | https://www.irccloud.com/pastebin/3ZOGt051/ |
| 22:34 | <TabAtkins> | You've maybe got something else interfering, because that snippet, pasted into my test file, works fine. ^_^ |
| 22:34 | <tobie> | TabAtkins: Mind giving the above a run? |
| 22:34 | <TabAtkins> | also just fine. What's the error you're getting? |
| 22:35 | <tobie> | FATAL ERROR: IDL SYNTAX ERROR LINE: 2 - skipped: "object createColor(double v1, double v2, double v3, optional double alpha)" |
| 22:35 | <TabAtkins> | that's weird then. definitely works just fine in my local. :/ |
| 22:36 | <TabAtkins> | try uploading that to the server versions? |
| 22:38 | <tobie> | TabAtkins: works |
| 22:39 | <tobie> | TabAtkins: o_O |
| 22:39 | <TabAtkins> | Suggests that your bikeshed version is old? |
| 22:39 | <TabAtkins> | `git log` and see what the latest patch's date is? |
| 22:43 | <tobie> | Must have ran "cmd + x" instead of "cmd + c" on a bikeshed src file and saved the file at some point. |
| 22:43 | tobie | facepalms. |
| 22:43 | <tobie> | https://www.irccloud.com/pastebin/NJzEdPsD/ |
| 22:44 | <tobie> | Glad I only wasted 10 minutes of your time with this and not a whole day of mine. |
| 22:44 | <tobie> | TabAtkins: Sorry. :-/ |
| 22:45 | <TabAtkins> | You didn't waste almost any of my time, no problem. ^_^ |
| 22:50 | <rniwa> | Domenic: are we invoking custom element callbacks when it's adopted into a template element's "inert" document? |
| 22:51 | <jyasskin> | TabAtkins / Domenic: https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-global has a data-dfn-for with a line break in it, which appears to be confusing Shepherd. I'm not sure if that's a bug in HTML or Shepherd. |
| 22:52 | <TabAtkins> | Hmm, must be a shepherd bug. What confusion is there? Is it dropping the text after the linebreak or something? |
| 22:53 | <jyasskin> | It's finding two different definitions, one with a 'for' of the text before the linebreak, and one with the text after. |
| 22:53 | <jyasskin> | `bikeshed refs --text 'global object'` shows it. |
| 23:04 | <TabAtkins> | Ah yeah, that's def a shepherd bug. I'll go report it. |
| 23:18 | <TabAtkins> | jyasskin: Okay, was a Bikeshed bug actually. Both Shepherd and Bikeshed are going to start normalizing whitespace to avoid this problem in the future. |
| 23:18 | <jyasskin> | TabAtkins: Thanks! |