| 04:00 | <MikeSmith> | for “trailing commas” in JavaScript syntax, is there any specific fragment ID in the EcmaScript spec I can point to? |
| 04:00 | <MikeSmith> | see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Trailing_commas for the context |
| 04:15 | <MikeSmith> | is that what Elision<sub>opt</sub> indicates? |
| 04:44 | <MikeSmith> | when I look at a proposal in https://github.com/tc39/proposal-* space, how can I tell if it’s already been adopted into the current https://tc39.github.io/ecma262/ standard? (short of actually checking the current spec text) |
| 04:45 | <MikeSmith> | e.g., looking at https://github.com/tc39/proposal-trailing-function-commas I cannot tell if it’s been adopted or not from just looking at that |
| 04:45 | <MikeSmith> | I think it has been, but there’s no statement there to indicate that |
| 04:50 | <MikeSmith> | OK looking at https://github.com/tc39/proposals I see it’s not listed there, so I guess the process is that I see a proposal in https://github.com/tc39/proposal-*, I need to check https://github.com/tc39/proposals and see if it’s listed there ー but if it’s not, then I need to assume it’s already been adopted |
| 04:52 | <MikeSmith> | ah |
| 04:52 | <MikeSmith> | now I find https://github.com/tc39/proposals/blob/master/finished-proposals.md |
| 05:08 | <MikeSmith> | filed https://github.com/tc39/proposals/issues/162 |
| 14:16 | <gsnedders> | so per spec HTMLAllCollection shouldn't have a @@iterator, right? |
| 14:16 | <gsnedders> | because it does in FF/Ch, at least |
| 14:17 | <gsnedders> | But I can't see any justification for that in the spec. |
| 14:25 | <ato> | ‘allo ‘allo |
| 14:26 | <ato> | I heard there was a discussion about document.all[Symbol.iterator]. |
| 14:26 | <ato> | Is that a thing that only exists in Gecko? |
| 14:26 | <gsnedders> | 14:16 < gsnedders> so per spec HTMLAllCollection shouldn't have a @@iterator, right? |
| 14:26 | <gsnedders> | 14:16 < gsnedders> because it does in FF/Ch, at least |
| 14:26 | <gsnedders> | 14:17 < gsnedders> But I can't see any justification for that in the spec. |
| 14:28 | <ato> | Oh interesting find. |
| 14:29 | <gsnedders> | I'm wondering if I've misread the spec here |
| 14:31 | <gsnedders> | I've misread WebIDL, I think. |
| 14:32 | <gsnedders> | "an indexed property getter and an integer-typed length attribute" |
| 14:32 | <gsnedders> | which they do, hence they have a @@iterator |
| 14:32 | <gsnedders> | okay, ignore me |
| 14:50 | <AutomatedTester> | stupid question about DOM. If we have a document element the assumption is that it includes all the mixins that come with document? |
| 14:51 | <gsnedders> | the document has them, the document elmenet is the root element |
| 14:52 | <annevk> | AutomatedTester: I don't really understand the question |
| 14:52 | <gsnedders> | unless you're not asking what I think you are? |
| 14:52 | <AutomatedTester> | I might not be asking it properly... |
| 14:54 | <AutomatedTester> | so my question is do I need to explicitly call out document or shadowRoot for knowing where items should start from. E.g. in webdriver we have the start node for finding elements as the document element but if I want to search a shadow dom I need to use the shadowRoot |
| 14:54 | <AutomatedTester> | so is having it as the document fine or do I need to explicitly say document or shadowRoot |
| 14:56 | <gsnedders> | AutomatedTester: what are you using to find things? I presume you just do it by reference to Selectors or XPath? |
| 14:56 | <AutomatedTester> | https://w3c.github.io/webdriver/#find-element step 7 to be exact |
| 14:56 | <AutomatedTester> | gsnedders: yes |
| 14:58 | <AutomatedTester> | since there is no way to pierce a shadow dom otherwise we break encapsulation we need to set the start node to the shadowRoot and then search which is the equivalent of shadowRoot.querySelector(...) |
| 15:03 | <annevk> | AutomatedTester: hmm, doesn't WebDriver have super powers anyway? Why not break encapsulation? |
| 15:04 | <AutomatedTester> | annevk: we could but then we need to build our own selectors for starting at the top level and descending into a shadow dom |
| 15:05 | <annevk> | AutomatedTester: anyway, if you want to go through shadow trees, you need to say so, and define how |
| 15:05 | <annevk> | AutomatedTester: there's no freebies |
| 15:05 | <AutomatedTester> | and I am not sure we can guarantee a view into closed shadow dom's |
| 15:05 | <AutomatedTester> | annevk: thats what I thought and just wanted to check |
| 15:06 | <annevk> | AutomatedTester: WebDriver should be able to do that I think, but it might require the browser to provide ways |
| 15:10 | <AutomatedTester> | annevk: what was the plan for testing this for end users or was this "webdriver will solve this... probably" |
| 15:16 | <annevk> | AutomatedTester: end users being? |
| 15:16 | <AutomatedTester> | annevk: website QA folk |
| 15:16 | <annevk> | AutomatedTester: I think the idea there was that WebDriver would indeed provide hooks |
| 15:17 | <ato> | gsnedders: I think [...collection] does some magic because for-of doesn’t work. |
| 15:17 | <annevk> | AutomatedTester: but there wasn't a lot of discussion about that, for sure |
| 15:17 | <ato> | gsnedders: I think reading ECMAScript might reveal some clues. |
| 15:18 | <gsnedders> | ato: both should just call the iterator, no? |
| 15:19 | <AutomatedTester> | annevk: my worry is that since deep selectors were dropped its going to be non-trivial to allow people to call from the document down into a shadow dom |
| 15:19 | <AutomatedTester> | feels like there are a lot of dragons down there |
| 15:21 | <gsnedders> | ato: for (let x of document.all) console.log(x); |
| 15:21 | <gsnedders> | ato: that wfm? |
| 15:21 | <ato> | gsnedders: OK, maybe HTMLAllCollection is not the problematic one here. |
| 15:21 | <ato> | https://searchfox.org/mozilla-central/source/testing/web-platform/tests/webdriver/tests/execute_script/collections.py for reference. |
| 15:23 | <ato> | HTMLFormControlsCollection works with for-of. |
| 15:23 | <ato> | And HTMLOptionsCollection. |
| 15:23 | <annevk> | AutomatedTester: I don't really know what folks are looking for, but you could offer things that basically iterate over the document and all its shadow roots and and match the selectors given |
| 15:24 | <ato> | And NodeList. |
| 15:24 | <annevk> | AutomatedTester: it's just that we don't want to expose those kind of things directly to web pages |
| 15:24 | <ato> | And HTMLCollection. |
| 15:24 | <AutomatedTester> | annevk: I think people want /deep/ |
| 15:25 | <annevk> | AutomatedTester: I guess I'm saying is that if they say that, we need to dig a little deeper since a) it doesn't work for closed trees and b) we don't want a different selector parser for WebDriver |
| 15:25 | <AutomatedTester> | agreed! |
| 15:26 | <AutomatedTester> | if I can offload to the webapi's then I can somewhat guarantee interop |
| 15:26 | <annevk> | AutomatedTester: we can offer utilities that do some kind of query on all shadow roots associated with a document and return nodes in some manner, but if we can't move the conversation past /deep/ I'd just let it slide for now... |
| 15:26 | <annevk> | (note that this APIs would have to be WebDriver only) |
| 15:27 | <annevk> | these* |
| 15:27 | <ato> | As does Arguments. |
| 15:27 | <AutomatedTester> | at the moment I can get around most cases (excluding closed shadow doms) using document or shadowRoot |
| 15:27 | <AutomatedTester> | and then base things off that |
| 15:28 | <AutomatedTester> | annevk: if I were to start a conversation about the searchability where is the best place to do that? |
| 15:28 | <annevk> | AutomatedTester: the WebDriver repo? |
| 15:29 | <annevk> | AutomatedTester: as I said, we don't want these to be web-exposed APIs |
| 15:29 | <AutomatedTester> | ok |
| 15:29 | <AutomatedTester> | I will just @ the relevant people like you to discuss things further |
| 15:29 | <AutomatedTester> | we have a thread there at the moment |
| 15:29 | <annevk> | AutomatedTester: it's reasonable to start a WebDriver-specific thread on w3c/webcomponents though to point folks at that |
| 15:29 | <ato> | gsnedders: What. Even FileList works with for-of. |
| 15:30 | <AutomatedTester> | annevk: thats what more what I was after :) |
| 15:30 | <annevk> | AutomatedTester: okay, yeah, please do that |
| 15:30 | <AutomatedTester> | will do |
| 15:30 | <ato> | gsnedders: OK, so am I right reading that the conclusion here is that it’s OK for the spec to rely on the collection implementing the Iterable interface? |
| 15:30 | <ato> | gsnedders: I mean the language I used is clearly wrong, but that we can use the normal iterator protocol? |
| 15:31 | <annevk> | ato: it's a feature of IDL |
| 15:31 | <annevk> | ato: IDL added it to reduce the amount of specifying we'd have to do to support it all over the place |
| 15:32 | <ato> | annevk: Let me point you to the actual bit of spec we’re discussing. |
| 15:33 | <ato> | annevk: In https://w3c.github.io/webdriver/#dfn-internal-json-clone-algorithm, under the “a collection” variant we say “For each item of value, …”. |
| 15:33 | <ato> | And collection is not quite the same as in DOM/HTML: https://w3c.github.io/webdriver/#dfn-collection |
| 15:33 | <ato> | (Here “type” should be “interface” I think.) |
| 15:34 | <ato> | But the effect we want to achieve is to rely on the each of these objects’ iterator protocols to run some JSON serialisation steps and add them to a JSON Array. |
| 15:34 | <gsnedders> | ato: no, we want something like "instance of" except we need it to work cross-origin |
| 15:34 | <gsnedders> | and I can't remember what the right way to define that |
| 15:34 | <ato> | gsnedders: Yes, I meant that actually! |
| 15:34 | <annevk> | the right way today is what you did |
| 15:35 | <annevk> | "is X" is the way to do that until we have [[PlatformBrand]] or equiv |
| 15:35 | <annevk> | now actually invoking the iterator protocol I don't know, that has all kinds of potential side effects that I'm not sure you want here? |
| 15:36 | <annevk> | in any event, simply saying "for of" doesn't cut it if you want to call JS operations |
| 15:39 | <ato> | We don’t particularly care how implementations do it, as long as the result of the algorithm is that you end up with a JSON Array with the objects passed through a serialisation step. |
| 15:39 | <ato> | So when you talk about side effects of invoking the iterator protocol and JS operations, I have a hard time understanding exactly what you mean. |
| 15:40 | <gsnedders> | iterators can execute arbitrary code |
| 15:40 | <gsnedders> | and throw exceptions, etc. |
| 15:40 | <ato> | Right, because they are custom? |
| 15:40 | <ato> | Or can be if the prototype has been replaced? |
| 15:41 | <annevk> | Various things, once you run JavaScript stuff can throw |
| 15:41 | <ato> | OK, so I don’t think the intention here is to run JS. |
| 15:41 | <annevk> | (and you'll also have to define other things, like what globals are in use and such) |
| 15:41 | <ato> | Right, and we do this for the actual script execution. |
| 15:41 | <ato> | (Where you receive a script string and inject it into the runtime.) |
| 15:42 | <gsnedders> | ato: e.g., if I set document.all[Symbol.iterator], the iterator is no longer the default |
| 15:42 | <ato> | gsnedders: Got it. |
| 15:43 | <ato> | Words are hard (-: |
| 15:44 | <ato> | So when we say “for item of value” here, that doesn’t invoke the JS Symbol.iterator or the iterator protocol. What does it do? |
| 15:44 | <ato> | Is it inferred as an exercise for the reader to understand that you want to achieve the effect of looking at a DOM/HTML collections items in sequence without going down the same path as JS? |
| 15:45 | <ato> | Not trying to be nitpicky here by the way. Just trying to understand how this works. |
| 15:45 | <annevk> | ato: it's not clear what it does since it's not defined |
| 15:46 | <ato> | In the Gecko implementation, what we do specifically is call what I guess is the initial value of the iterator protocol by doing [...collection] in XPCOM. |
| 15:46 | <gsnedders> | ato: it does invoke the iterator protocol? |
| 15:46 | <ato> | Doesn’t the JS spread operator do that? |
| 15:47 | <ato> | https://searchfox.org/mozilla-central/rev/b096dcf0ea226af628fe03f7e7acb56a25853533/testing/marionette/evaluate.js#250-253 |
| 15:47 | <gsnedders> | yes |
| 15:47 | <gsnedders> | both do that |
| 16:12 | <Domenic> | ato: I think you want to convert from JS into Infra or Web IDL data structures as soon as possible. Then you can operate without running JS side effects. |
| 16:13 | <Domenic> | Although, I guess that conversion will itself have JS side effects |
| 16:13 | <Domenic> | So you need to go deeper -_- |
| 16:13 | <annevk> | Domenic: so nobody working on Chrome's service worker implementation was considering this or they actively ruled out preloading one already somehow? |
| 16:13 | <Domenic> | annevk: from what they've told me there are engineering challenges with first-run service worker that they have no plans on solving |
| 16:14 | <annevk> | For Firefox it's only the former as far as I know, the latter is to be seen |
| 16:14 | <annevk> | Domenic: are those documented somewhere? |
| 16:14 | <Domenic> | Not that I know of |
| 16:14 | <annevk> | Domenic: who would I ask? |
| 16:14 | <ato> | Domenic: Other implemenations are in Rust and C++, so we don’t want to tie the spec to JS if we can avoid it. |
| 16:14 | <Domenic> | But their vibe was that it was kind of common knowledge, so I dunno, maybe? |
| 16:15 | <ato> | Domenic: But I don’t really understand what you’re proposing… |
| 16:16 | <Domenic> | ato: My best guess so far is something like "for each supported property index (https://heycam.github.io/webidl/#dfn-supported-property-indices), run the algorithm specified for the collection's indexed property getter (https://heycam.github.io/webidl/#dfn-indexed-property-getter)"; and collect all those into a list (https://infra.spec.whatwg.org/#lists) |
| 16:16 | <Domenic> | annevk: kinuko and matto |
| 16:17 | <annevk> | Domenic: thanks |
| 16:17 | <Domenic> | ato: for Arrays you're totally screwed though, you'll have to run JS with side effects. E.g if someone does `new Array(3); Object.defineProperty(Array.prototype, "1", { get () { throw new Error("foo"); } })` there's no way to avoid hitting that exception |
| 16:19 | <Domenic> | ato: It appears you're also screwed for Arguments objects in a very similar way |
| 16:20 | <Domenic> | By "screwed" I mean "you'll run JS", not "unimplementable in Rust and C++" |
| 16:20 | <Domenic> | Rust and C++ implementations just need to use the JS API |
| 16:21 | <Domenic> | s/JS API/JS engine API |
| 16:30 | <ato> | Domenic: Thanks for explaining that, very useful! |
| 16:30 | <ato> | Domenic: So we are aware of the pitfalls that we can’t trust the input data to the algorithm, and I don’t think we particularly care that we fail in this case. |
| 16:31 | <ato> | Domenic: If a website makes an array throw an error on iteration and you try to return that array using an injected script, you would expect that behaviour. |
| 16:31 | <gsnedders> | ato: but we do need to define well the failure case |
| 16:31 | <ato> | Yes, that sounds like what is missing here. |
| 16:31 | <ato> | Or, I mean, generally throughout the spec. |
| 16:31 | <Domenic> | +1. Ideally with tests ;) |
| 16:32 | <ato> | For the other commands in the specification, we expect them to work irregardless of prototype overrides. |
| 16:32 | <ato> | So it would be funny to see what happens if you inject a script replacing querySelectorAll or whatever and then you try using the Find Elements WebDriver command. |
| 16:32 | <ato> | My guess is that hillarity would ensue depending on the implementation. |
| 16:33 | <nox> | Domenic: How does jsdom cope with such Array.prototype shenanigans btw? |
| 16:33 | <ato> | It’s not entirely clear to me how to define these error scenarios, but I’ll file a bug and we can take it from there. |
| 16:34 | <ato> | It sounds like “define error scenarios” is orthogonal from s/type/instance of/ and indeed how to say “for item of value”. |
| 16:34 | <Domenic> | nox: it doesn't, yet. We haven't tried to harden it. But it could via the various techniques discussed here: https://github.com/domenic/get-originals/blob/master/Sample%20conversion.md#array-manipulation-analysis . (That doc uses a hypothetical "get originals" API, but jsdom has access to the originals via other means, so that part isn't necessary.) |
| 16:34 | <nox> | Domenic: Thanks for the link. |
| 16:34 | <Domenic> | ato: I think "define error semantics" is not orthogonal to "for item of value" because how you iterate is what generates or hides errors. |
| 16:35 | <ato> | You’re right. But maybe we can do it in steps. |
| 16:35 | <ato> | Would you say “for item of value” is the right terminology here? |
| 16:36 | <Domenic> | No |
| 16:36 | <Domenic> | Because it's not defined |
| 16:47 | <ato> | https://github.com/w3c/webdriver/issues/1349 |
| 20:08 | <nox> | Domenic: For Array, could we wrap them in a Proxy that uses the original Object.defineProperty in its set method? |
| 20:09 | <nox> | To be able to still do a[i] = x |
| 20:16 | <Domenic> | nox: hmm yeah that seems pretty good, +1 |
| 20:20 | <nox> | Domenic: And is there any way to use Array.values and Array.of to copy an array avoiding holes and stuff like that? |
| 20:21 | <Domenic> | nox: not sure what you mean |
| 20:21 | <Domenic> | Is this for the input, i.e. implementing the sequence<> -> list conversion? |
| 20:21 | <Domenic> | In that case the per-spec thing is to just use the iterator protocol, for-of |
| 20:21 | <nox> | Yeah. |
| 20:21 | <nox> | Oh right. |
| 21:19 | <nox> | Domenic: With such an Array proxy, couldn't we also allow array method calls with the certainty that we are calling the original ones from Array.prototype? |
| 21:19 | <Domenic> | nox: I'm not sure exactly how to write it, but it's definitely true that with a proxy you could make myProxy.map() always do the right thing. |
| 21:20 | <nox> | Domenic: I was thinking something way more generic than that, like makeAProxyHandlerThatWillCallExactlyTheCurrentMethodsOfThatGivenPrototype(Array.prototype). |
| 21:20 | <Domenic> | Yeah, I mean, that seems doable. Writing proxies is such an art though. |
| 21:21 | <Domenic> | Also you'd need to save each method you're interested in, to avoid people deleting Array.prototype.map at runtime and thus messing you up |
| 21:22 | <Domenic> | Array methods are not a real big deal though. If you're saving them anyway, you can just do arrayMap(myProxy, mapper) which is almost as nice. |
| 21:22 | <nox> | Domenic: Hence why a proxy handler constructed from the prototype. |
| 23:03 | <MikeSmith> | I wonder if anybody has any clue why every time I now try to do a Google search in Canary, I only instead get a generated error page from Canary about an Origin Policy violation |
| 23:03 | <MikeSmith> | Well, well, well. What do we have here? An Origin Policy violation. |
| 23:03 | <MikeSmith> | And what do we not have? A page! |
| 23:03 | <MikeSmith> | You're trying to go to: https://www.google.co.jp/search?q=foo&oq=foo&aqs=chrome..69i57j69i60j69i61j69i60j0l2.776j0j9&sourceid=chrome&ie=UTF-8 |
| 23:03 | <MikeSmith> | The policy applies to: https://www.google.co.jp |
| 23:25 | <Domenic> | You must be in some experiment group |
| 23:25 | <Domenic> | Or with a flag flipped |
| 23:25 | <Domenic> | And google.co.jp implemented something wrong |