| 00:44 | <MikeSmith> | hah :) |
| 01:36 | <MikeSmith> | caitp: jochen__ hayato any insight on https://bugs.chromium.org/p/chromium/issues/detail?id=636112 |
| 01:36 | <MikeSmith> | test failures in blink of the form, class string of PaymentRequest.prototype expected "[object PaymentRequestPrototype]" but got "[object PaymentRequest]" |
| 01:36 | <MikeSmith> | for various types |
| 01:37 | <MikeSmith> | or see https://bugs.chromium.org/p/chromium/issues/detail?id=635694 because I think my issue there is probably just a duplicate of the (general) problem described tehre |
| 01:43 | MikeSmith | bugs yukishiino over on #chromium |
| 02:21 | <Domenic> | MikeSmith: this is an intentional change |
| 02:21 | <Domenic> | MikeSmith: there is a Web IDL spec bug open on it |
| 02:23 | <rniwa> | Domenic: hi |
| 02:23 | <rniwa> | Domenic: so it looks like Chrome doesn't throw when calling customElements.define('a-b', HTMLElement) |
| 02:23 | <rniwa> | Domenic: but the indent is to throw in that case, right? |
| 02:24 | <rniwa> | (per step 2 of https://html.spec.whatwg.org/#dom-customelementsregistry-define) |
| 02:24 | <Domenic> | rniwa: yeah definitely. I thought that was being worked on very recently, maybe it hasn't landed... |
| 02:24 | <rniwa> | Domenic: okay, it fails as of 54.0.2825.0 |
| 02:25 | <Domenic> | rniwa: I'll file the bug if there's not one open already. Thanks. |
| 02:25 | <rniwa> | Domenic: it would be really useful for all of us to get gather and make sure our implementation of shadow DOM & custom elements are consistent |
| 02:25 | <rniwa> | Domenic: there have been enough moving parts in the spec that I'm afraid one of us is going to miss something |
| 02:25 | <Domenic> | rniwa: yeah I know dominiccooney is intending to upstream the tests to WPT format; he's been writing a lot in testharness.js style |
| 02:25 | <rniwa> | Domenic: cool |
| 02:26 | <rniwa> | Domenic: we also have a dozen or so tests that I'm intending to upstream |
| 02:28 | <rniwa> | Domenic: so this step 2 is somewhat problematic & ambiguous |
| 02:29 | <Domenic> | :( |
| 02:29 | <rniwa> | Domenic: how are we supposed to be checking the inheritance? |
| 02:29 | <Domenic> | rniwa: via the inherited interfaces concept defined in Web IDL? |
| 02:29 | <rniwa> | Domenic: because it's totally possible for author to override prototype/__proto__ of HTMLInputElement |
| 02:29 | <rniwa> | Domenic: and make it a getter, right? |
| 02:29 | <Domenic> | Right it's a static relationship |
| 02:30 | <rniwa> | Domenic: ah, okay |
| 02:30 | <Domenic> | Not instanceof |
| 02:47 | <rniwa> | Domenic: so that poses a different challenge that I don't think we have any mechanism to check something like that in our engine |
| 02:47 | <rniwa> | Domenic: right now, this isn't an issue because none of subclasses of HTMLElement is constructible but |
| 02:48 | <Domenic> | rniwa: right, when I was adding that I tried to ask if it was something implementable. I'm open to other strategies as long as we maintain the invariant that you can't have a HTMLButtonElement with a local name that is not button. |
| 02:50 | <rniwa> | Domenic: It seems a bit strange to specifically throw an exception on HTMLElement and its subclasses |
| 02:50 | <rniwa> | Domenic: when we don't throw on SVGElement, Text, Range, etc... |
| 02:51 | <Domenic> | rniwa: trying to page this back in... I believe the problem is that the others will fail later, whereas HTMLElement and its subclasses will not. |
| 02:51 | <Domenic> | rniwa: right, the others will fail at https://dom.spec.whatwg.org/#concept-create-element step 6.1.3 |
| 02:51 | <rniwa> | Domenic: it can certainly fail if we checked new.target |
| 02:52 | <Domenic> | Hmm |
| 02:53 | <rniwa> | Domenic: it's fairly easy for us to check that something inherits from HTMLElement and then it's not one of DOM classes |
| 02:53 | <rniwa> | Domenic: so we can just do that to throw an exception in that case |
| 02:53 | <rniwa> | Domenic: since new.target can't be getter, etc... this is basically unobservable from scripts |
| 02:53 | <Domenic> | rniwa: can you open an issue if you think we should change this? I want to be sure I have time to go through all the implications and I'm heading to bed soon. I imagine changing it will be possible but I remember investigating this a few weeks ago and thinking that the current spec was the alternative I liked the most, but not strongly. |
| 02:54 | <rniwa> | Domenic: sure |
| 02:54 | <rniwa> | Domenic: I'm gonna do that on webcomponents issue tracker for now |
| 02:54 | <Domenic> | sounds good |
| 03:08 | <MikeSmith> | mkwst: I think https://mikewest.github.io/origin-policy/ is pretty clearly already sufficiently viable enough to merit being moved into https://github.com/wicg if you wanted to |
| 03:09 | <MikeSmith> | mkwst: though I don’t really know what the WICG criteria are for accepting new repos |
| 03:09 | <MikeSmith> | mkwst: nor am I saying it would be necessarily a win to move it |
| 04:43 | <annevk> | mkwst is relaxing, try again next week |
| 05:05 | <MikeSmith> | annevk: ah OK |
| 05:06 | <MikeSmith> | tobie: for WebIDL please consider prioritizing https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244 for resolution |
| 07:09 | <annevk> | Opera hasn't hired a new foolip thus far, email address bounces |
| 07:09 | annevk | did a reply-all to an old Blink thread |
| 07:23 | <annevk> | Sebmaster: did you see https://twitter.com/jasnell/status/763479355196596224 btw? |
| 07:24 | <annevk> | I wonder if Sam Ruby has been involved with that since they're both at IBM or if that organization is so large it just sorta happened |
| 07:44 | <Ms2ger> | annevk, https://bugzilla.mozilla.org/show_bug.cgi?id=1294100 |
| 07:47 | <annevk> | Ms2ger: sigh |
| 07:47 | <annevk> | Ms2ger: I guess we can overload if it gets bad |
| 07:48 | <annevk> | Ms2ger: not the end of the world and certainly not the ugliest API, but why do we always try? |
| 07:49 | <annevk> | Ms2ger: left a comment |
| 07:50 | <Ms2ger> | Thanks |
| 08:05 | <Ms2ger> | One more stupid extension gone: https://hg.mozilla.org/mozilla-central/rev/0ca0282fe48b |
| 08:05 | <annevk> | Whoa, Thomas is all over the map |
| 08:25 | <foolip> | annevk: :) If you have philipj⊙oc in bugs or email threads, please do replace with something not so bouncy |
| 08:27 | <tobie> | MikeSmith: mmm. |
| 08:36 | <tobie> | MikeSmith: I'm new to this. What's the strategy here? Toss a coin and beat whomever doesn't accept that resolution until they do? |
| 09:02 | <MikeSmith> | tobie: dunno, really. Maybe Domenic has some good suggestion |
| 09:03 | <MikeSmith> | tobie: if you actually change the spec maybe bz would reconsider |
| 09:04 | <MikeSmith> | would be good to get more details from him or others at mozilla about the compat problems he alludes to |
| 09:06 | <MikeSmith> | foolip might also have some insight on https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244 |
| 09:17 | <foolip> | MikeSmith: ugh, not sure what to make of that |
| 09:20 | <annevk> | JakeA: https://twitter.com/jaffathecake/status/763662818277265408 is a great sketch |
| 09:20 | <annevk> | JakeA: not a fair comparison though 😊 |
| 09:20 | <JakeA> | It pops into my head loads |
| 09:22 | <JakeA> | Just read an article where the UK divers offered their "reckons" about the green water in Rio. "we think maybe a load of ink has run into the pool" |
| 09:24 | <MikeSmith> | foolip: yeah me neither I just want to know what expectations to write into the IDL test harness |
| 09:28 | <foolip> | MikeSmith: asked for clarification |
| 09:33 | <MikeSmith> | thanks will try to find a test for an interface that all browsers actually implement |
| 09:37 | <tobie> | Yeah. The only reasonable thing to spec is that this behavior is implementation specific. :p |
| 09:38 | <tobie> | MikeSmith: you're working on idlharness? That's awesome! |
| 09:39 | <MikeSmith> | foolip: for now you can look at the results of http://w3c-test.org/webstorage/idlharness.html though that obscures what exactly is being called |
| 09:39 | <zcorpan> | hmmmm. old apple docs still has <menuitem><menu>. chromium with experimental web platform features enabled now parses like firefox. i suppose i should give up and spec reality :-| |
| 09:39 | <MikeSmith> | tobie: I will try to pull out what actual call will cause it |
| 09:39 | <MikeSmith> | s/tobie/foolip/ |
| 09:40 | <MikeSmith> | tobie: not working on it actively but instead just planning to update it to align with any spec changes or any places where it might not conform to the current spec |
| 09:42 | <foolip> | wait, do we have any reason do thing that the current non-interoperable state is required for compat? I thought it was just a case of nobody quite being motivated to care in any engine. |
| 09:47 | <annevk> | Hmm, Polymer apparently though it was fine to encourage everyone to use document.createElement(string, string) |
| 09:47 | <annevk> | Per the bug Ms2ger referenced earlier, so I guess we'll have to support that |
| 09:54 | <smaug____> | uh, this toString() handling |
| 09:55 | <smaug____> | I wish I understood why blink wants the behavior they have |
| 09:55 | <annevk> | smaug____: v0 of custom elements didn't use a dictionary |
| 09:56 | <annevk> | smaug____: and v0 appears to be leaking |
| 09:56 | <annevk> | smaug____: despite the promise from Google that changes would be possible due to usage of libraries and such |
| 09:56 | <MikeSmith> | foolip: actually as far as the test I guess I am just overcomplicating this |
| 09:57 | <MikeSmith> | foolip: you just do, e.g., (new Object()).toString.call(StorageEvent.prototype) |
| 09:57 | <MikeSmith> | and from Gecko you will see "[object StorageEventPrototype]" but from Blink you will see "[object StorageEvent]" |
| 09:58 | <foolip> | annevk: isn't that typeExtension extra argument in some spec? |
| 09:58 | <smaug____> | annevk: that is unrelated to my toString() complains |
| 09:58 | <annevk> | smaug____: oh sorry |
| 09:58 | <annevk> | smaug____: you're talking about the IDL thing |
| 09:59 | <smaug____> | annevk: but yes, we had to fix something in Gecko recently because someone was passing 2nd param to createElement |
| 09:59 | <smaug____> | annevk: yes |
| 09:59 | <smaug____> | was just reading bugmail |
| 09:59 | <smaug____> | and testing blink |
| 09:59 | <smaug____> | it makes really no sense |
| 09:59 | <annevk> | foolip: it's a dictionary these days |
| 09:59 | <smaug____> | I don't care too much, but the behavior what blink has now makes no sense |
| 09:59 | <foolip> | annevk: oh. I wonder if anyone considered whether changing that in Blink is actually web compatible |
| 09:59 | <annevk> | smaug____: for toStringTag you mean? |
| 09:59 | <smaug____> | and I don't understand the reasoning |
| 10:00 | <smaug____> | well, toString() |
| 10:00 | <annevk> | smaug____: I think the reason is that TC39 introduced @@toStringTag or whatever it's called, exposing toString() in some way |
| 10:01 | <annevk> | smaug____: so then the question was how that should work for IDL |
| 10:01 | <annevk> | Anyway, I don't really care strongly about it either way |
| 10:02 | <smaug____> | annevk: and that other thing... where is Polymer encouraging everyone to use createElement(string, string) ? |
| 10:04 | <smaug____> | hmm, I don't even know what happens when string is passed as a param which expects dictionary |
| 10:04 | <smaug____> | exception |
| 10:06 | <annevk> | smaug____: see the link to the polymer documentation |
| 10:06 | <annevk> | smaug____: if you scroll down a bit it's there |
| 10:06 | <smaug____> | ah, I need to look at the log |
| 10:11 | <smaug____> | annevk: ok, so spec should possibly allow string as param, and do nothing with it? |
| 10:46 | <Ms2ger> | Yeah |
| 12:08 | <Domenic> | foolip: MikeSmith: Blink cares and would prefer to follow the JavaScript pattern of [object Foo] instead of divergent [object Foo] + [object FooPrototype] |
| 12:09 | <Ms2ger> | Blink wanna ship it? |
| 12:09 | <Domenic> | We already have for like 5 releases |
| 12:10 | <Ms2ger> | Even better |
| 13:11 | <Sebmaster> | annevk: yes, saw it live even. Apparently they're not sure how to handle spec updates wrt semver yet, so this is going to be very interesting |
| 13:18 | <Domenic> | oh fascinating |
| 13:18 | <Sebmaster> | Personally I hope they follow properly, I wouldn't want to keep the slower lib maintained if it's not necessary |
| 13:19 | <Sebmaster> | But then browsers don't follow it quite either, so it'd be necessary for shims anyways :( |
| 13:20 | <annevk> | Yeah, Gecko is slowly getting there |
| 13:20 | <annevk> | It's hard to get anyone from Blink engaged |
| 13:20 | <annevk> | WebKit might a few minor tweaks, but nothing major |
| 13:20 | <annevk> | And I suspect Edge will be the last |
| 13:21 | <annevk> | E.g., someone has been implementing IPv4 parsing and canonicalizing in Gecko, which is nice |
| 13:21 | <foolip> | annevk: is this about the @@toStringTag thing, or is there another thing where you can't get any Blink reaction |
| 13:21 | <annevk> | foolip: this was about URL parsing |
| 13:22 | <annevk> | foolip: there's also something about the Origin header I've been waiting 9 months on or so now |
| 13:22 | <annevk> | foolip: it's not a continuous effort on my part though and the Blink side may have forgotten about it |
| 13:22 | <foolip> | Oh. I guess URL is hard because you need to figure out how to actually transition. |
| 13:23 | <foolip> | Also because the code itself doesn't live in Blink I suppose. |
| 14:10 | <zcorpan> | annevk: (and others going to tpac), interested in sharing airbnb? |
| 14:55 | <Domenic> | Do the fetch() web platform tests all live in service-workers/? |
| 14:55 | <Domenic> | nope, I'm just blind |
| 15:12 | <Domenic> | annevk: any ideas on how to test a Response's HTTPS state? |
| 15:16 | <annevk> | Domenic: hmm not really |
| 15:16 | <Domenic> | What is it used for anyway? |
| 15:16 | <Domenic> | I just know you and mkwst are very conscious to propagate it everywhere :) |
| 15:18 | <annevk> | Domenic: it's used to determine whether you get powerful API access |
| 15:18 | <annevk> | Domenic: secure contexts, basically |
| 15:18 | <Domenic> | Hmm |
| 15:19 | <Domenic> | Yeah not sure how that could be tested... I imagine it would only matter for Responses served from a service worker, which will always have a HTTPS settings object |
| 15:19 | <Domenic> | Oh maybe I could importScripts from an insecure origin |
| 15:19 | <annevk> | Yeah, think so |
| 15:20 | <Domenic> | No wait that doesn't work, still the same global |
| 15:21 | <Domenic> | annevk: https://github.com/w3c/web-platform-tests/pull/3452 FYI |
| 15:58 | <bradleymeck> | if I am reading https://url.spec.whatwg.org/ right `new URL('file://../..') should not normalize away the 2 `..` segments? https://url.spec.whatwg.org/#path-state 2. (noop due to https://url.spec.whatwg.org/#pop-a-urls-path file exception) |
| 15:58 | <bradleymeck> | is that correct? |
| 16:00 | <Domenic> | seems right, let's test the reference implementation... |
| 16:01 | <Domenic> | https://www.irccloud.com/pastebin/wgD0KlaR/ |
| 16:01 | <Domenic> | That's not promising... |
| 16:01 | <Domenic> | (whatwg-url might have a bug, or the spec might be crazy, but that doesn't seem good in any case) |
| 16:03 | <Domenic> | bradleymeck: are you sure the predicate at the top of path state step 1 is true? |
| 16:04 | <Domenic> | I'd debug through the whatwg-url implementation to see what's going on |
| 16:04 | <bradleymeck> | i think `c is EOF code point or "/"` should be true since it consumes a `/` |
| 16:05 | <Domenic> | Hmm |
| 16:05 | <Domenic> | I thought c would be . here |
| 16:06 | <Domenic> | But yeah I can't really trust myself to get this right at a glance, and don't have time to dig into it in detail, so I dunno. It does seem possible the result is wrong. But as for what's going on I'd debug through whatwg-url to confirm. |
| 16:07 | <bradleymeck> | i can take a look because trying to figure out what import of a url would look like for node, thanks |
| 16:09 | <Domenic> | Hmm I thought you'd do `new URL(importSpecifier, "file://" + __filename)` for that |
| 16:16 | <bradleymeck> | node modules are not directly mapped to files though |
| 16:16 | <bradleymeck> | importSpecifier for "module" and "@scope/module" don't work I think |
| 16:17 | <Domenic> | Yeah true |
| 16:18 | <Domenic> | Anything that doesn't start with ./, ../, or / would be handled specially I think |
| 16:20 | <bradleymeck> | trying to figure out the exact mechanics of that but yea |
| 16:22 | <bradleymeck> | the idea in #node-dev was to resolve using a `new URL(new URL(importSpecifier, "node://"), "file://" + __filename)` basically |
| 16:22 | <bradleymeck> | but saw that importSpecifier was auto-normalizing without any way to turn it off |
| 16:31 | <annevk> | I did not know about https://news.ycombinator.com/item?id=11175258 |
| 16:31 | <annevk> | Seems very exciting if it works out |
| 16:32 | <annevk> | Hundreds of FPS is what VR needs |
| 16:35 | <annevk> | bradleymeck: I think in HTML the model is that you first do syntax checks on the identifier |
| 16:35 | <annevk> | bradleymeck: afterwards you hand it to the parser |
| 16:36 | <bradleymeck> | they do prefix checking, which we will need to do |
| 16:36 | <bradleymeck> | but after that we are in new territory |
| 16:37 | <bradleymeck> | prefix of ./ ../ or / will definitely need to resolve against current script, modules need to use node_modules (suggested node:// scheme) |
| 16:38 | <bradleymeck> | but noticed that any non-file url in spec should auto-normalize which is a pretty no-go, so reading spec and saw this maybe bug? |
| 16:56 | <Domenic> | annevk: any reason sendBeacon spec does not use Fetch's keep-alive flag? |
| 17:00 | <annevk> | Domenic: prolly bug |
| 17:01 | <annevk> | bradleymeck: I don't really follow |
| 17:03 | <bradleymeck> | Domenic: https://github.com/jsdom/whatwg-url/pull/58 looked like a bug in whatwg-url, but unsure about that test that it makes fail, just gonna hand off here |
| 17:04 | <Domenic> | bradleymeck: wow nice find... the definition of "pop" is different than normal, that's awesome :-/ |
| 17:07 | <annevk> | Domenic: ah, I guess I can replace pop with shorten |
| 17:07 | <annevk> | Domenic: it used to match, but then I had to add a special case, but I kept the term |
| 17:07 | <Domenic> | that would be nice |
| 17:08 | <annevk> | https://github.com/whatwg/url/issues/140 |
| 17:09 | <annevk> | Domenic: https://aturon.github.io/blog/2016/08/11/futures/ might be of interest |
| 17:10 | <annevk> | Domenic: with streams they don't talk about backpressure at all, I wonder if that's a problem |
| 17:15 | <annevk> | Pffff https://github.com/Polymer/docs/issues/1705 |
| 23:16 | <MikeSmith> | annevk: http://stackoverflow.com/questions/38907385/should-non-2xx-status-code-responses-include-cors-specific-headers |