IRC log of webdriver on 2019-09-19

Timestamps are in UTC.

00:13:49 [RRSAgent]
RRSAgent has joined #webdriver
00:13:49 [RRSAgent]
logging to https://www.w3.org/2019/09/19-webdriver-irc
00:14:34 [CalebRouleau]
CalebRouleau has joined #webdriver
00:14:36 [jgraham]
RRSAgent, this meeting spans midnight
00:14:43 [jgraham]
RRSAgent make logs public
00:14:52 [jgraham]
RRSAgent make minutes
00:16:00 [jgraham]
RRSAgent create the minutes v2
00:17:30 [jgraham]
RRSAgent, make logs public
00:17:35 [jgraham]
RRSAgent, create the minutes v2
00:17:35 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html jgraham
00:19:49 [Zakim]
Zakim has joined #webdriver
00:23:34 [jwer_]
jwer_ has joined #webdriver
00:24:09 [bwalderman]
bwalderman has joined #webdriver
00:24:14 [plh]
plh has joined #webdriver
00:24:18 [plh]
https://mit.webex.com/mit/j.php?MTID=mf0c6a95eedfa61b9e4d6dbdc08e3798a
00:24:29 [plh]
Meeting number:
00:24:30 [plh]
644 219 299
00:24:30 [plh]
Password:
00:24:30 [plh]
w3c
00:27:14 [plh]
https://docs.google.com/presentation/d/1jKiPIrbIH6RdJE15nYWA-xr1DDVuYAeurpfhu6Dug-c/edit#slide=id.g5e27cbf49c_0_0
00:28:01 [simonstewart]
simonstewart has joined #webdriver
00:28:28 [simonstewart]
G'day, one and all
00:29:46 [ato]
Meeting: Browser Tools- and Testing WG, Day 1, TPAC 2019, Fukuoka
00:29:54 [ato]
Present+
00:30:06 [zghadyali]
zghadyali has joined #webdriver
00:30:20 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html ato
00:31:32 [projector_webdriver]
projector_webdriver has joined #webdriver
00:31:42 [plh]
https://mit.webex.com/mit/j.php?MTID=mf0c6a95eedfa61b9e4d6dbdc08e3798a
00:31:50 [simonstewart]
Present+
00:31:55 [cb]
present+
00:32:24 [Boaz]
Boaz has joined #webdriver
00:32:25 [jgraham]
present+
00:32:25 [Boaz]
present+
00:32:27 [twisniewski]
twisniewski has joined #webdriver
00:32:32 [miketaylr]
miketaylr has joined #webdriver
00:32:44 [JohnChen]
JohnChen has joined #webdriver
00:32:53 [Boaz]
agenda: https://www.w3.org/wiki/Webdriver/2019-TPAC
00:33:24 [titusfortner]
titusfortner has joined #webdriver
00:34:22 [AutomatedTester]
present+ David Burns, Mozilla
00:34:37 [JohnJansen]
present+
00:34:50 [JohnJansen]
present?
00:34:52 [CalebRouleau]
present+
00:34:59 [bwalderman]
present+
00:34:59 [JohnJansen]
rrsagent, make minutes
00:34:59 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html JohnJansen
00:35:00 [ato]
Seat map: https://docs.google.com/spreadsheets/d/1mZGuKR4SR6HGhqf4wTJQg6eJQBkqnP4G3ibkPTIP_1Q/edit#gid=0
00:35:00 [mmerrell]
present+
00:35:01 [twisniewski]
present+
00:35:04 [titusfortner]
present+
00:35:09 [CalebRouleau]
present+
00:35:14 [zghadyali]
present+
00:35:16 [lukebjerring]
lukebjerring has joined #webdriver
00:35:16 [JohnJansen]
present+
00:35:21 [zcorpan]
zcorpan has joined #webdriver
00:35:24 [lukebjerring]
present+
00:35:28 [zcorpan]
present+
00:35:29 [miketaylr]
present+
00:35:42 [MikeSmith]
present+
00:35:43 [drousso]
drousso has joined #webdriver
00:35:46 [JohnChen]
present+
00:35:49 [drousso]
present+
00:35:51 [diemol]
present+
00:36:07 [ato]
https://docs.google.com/spreadsheets/d/1mZGuKR4SR6HGhqf4wTJQg6eJQBkqnP4G3ibkPTIP_1Q/edit#gid=0
00:36:44 [JohnJansen]
rrsagent, make minutes
00:36:44 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html JohnJansen
00:37:23 [heejin]
heejin has joined #webdriver
00:37:34 [AutomatedTester]
https://www.w3.org/wiki/Webdriver/2019-TPAC
00:38:07 [plh]
https://docs.google.com/presentation/d/1jKiPIrbIH6RdJE15nYWA-xr1DDVuYAeurpfhu6Dug-c/edit#slide=id.g5e27cbf49c_0_0
00:38:18 [JohnJansen]
proposed items from me: https://www.w3.org/wiki/Webdriver/2019-TPAC
00:39:05 [ato]
Topic: Continuous Standards Development
00:39:27 [ato]
https://docs.google.com/presentation/d/1jKiPIrbIH6RdJE15nYWA-xr1DDVuYAeurpfhu6Dug-c/edit#slide=id.g5e27cbf49c_0_0
00:39:32 [brrian]
present+
00:39:33 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html ato
00:39:36 [AutomatedTester]
present+ David Burns
00:58:19 [zcorpan]
zcorpan has joined #webdriver
01:00:51 [Hexcles]
Hexcles has joined #webdriver
01:02:47 [ato]
Topic: Agenda
01:02:53 [ato]
ScribeNick: ato
01:02:55 [ato]
Topic: Agenda
01:03:02 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html ato
01:09:38 [ato]
Chair: AutomatedTester
01:09:47 [ato]
s/David//
01:09:50 [ato]
s/Burns//
01:15:52 [jugglinmike]
jugglinmike has joined #webdriver
01:23:14 [Hexcles]
Hexcles has joined #webdriver
01:53:44 [drousso]
drousso has joined #webdriver
01:54:51 [Hexcles]
Hexcles has joined #webdriver
01:55:34 [bwalderman]
bwalderman has joined #webdriver
01:56:33 [titusfortner]
titusfortner has joined #webdriver
01:57:43 [ato]
Agenda prioritised: https://www.w3.org/wiki/Webdriver/2019-TPAC
01:57:48 [diemol]
diemol has joined #webdriver
01:57:50 [ato]
RRS, make minutes
01:58:18 [JohnJansen]
RRSAgent, make minutes
01:58:18 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html JohnJansen
01:59:37 [ato]
s/David_Burns//
01:59:52 [ato]
s/Mozilla//
02:01:15 [Boaz]
Boaz has joined #webdriver
02:01:21 [Boaz]
present+
02:01:33 [JohnJansen]
present+
02:01:38 [mmerrell]
mmerrell has joined #webdriver
02:01:39 [CalebRouleau]
CalebRouleau has joined #webdriver
02:01:43 [ato]
ScribeNick: mmerrell
02:02:04 [ato]
Seat map: https://docs.google.com/spreadsheets/d/1mZGuKR4SR6HGhqf4wTJQg6eJQBkqnP4G3ibkPTIP_1Q/edit#gid=0
02:02:22 [diemol]
present+ Diego Molina, Sauce Labs
02:02:35 [simonstewart]
present+
02:02:53 [JohnJansen]
you cannot use a comma in your "present"
02:02:55 [mmerrell]
Topic: Bi-directional communication
02:03:04 [JohnJansen]
it looks like Sauce Labs is here :-)
02:03:17 [simonstewart]
In a sense, they are
02:03:28 [mmerrell]
jgraham: we need timeslots for the discussions
02:03:46 [mmerrell]
AutomatedTester: discuss until 12:30, at which point we'll break for lunch
02:03:49 [JohnJansen]
RRSAgent, make minutes
02:03:49 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html JohnJansen
02:04:30 [ato]
s/Sauce_Labs//
02:04:42 [ato]
s/Diego_Molina//
02:04:57 [Boaz]
agenda: https://docs.google.com/document/d/1gUm7Be-akW2-4mjr15cnZlzwoAfOlfL7b3tWCDrb1Jg/edit
02:06:17 [mmerrell]
Boaz: there's another agenda topic: articulating a workflow or set of guidelines for how to use the interfaces to create test materials
02:06:25 [mmerrell]
Boaz: specifically for browser vendors
02:06:35 [mmerrell]
Boaz: propose discussing that for Friday afternoon
02:07:09 [mmerrell]
AutomatedTester: lunch 12:30-1:30, break 3:30 - 4, at which point we do the Aria Driver demo
02:07:16 [nao_watanabe_access]
nao_watanabe_access has joined #webdriver
02:07:55 [npm]
npm has joined #webdriver
02:08:37 [mmerrell]
jgraham: "bi-di" is short for "bi-directional WebDriver"
02:08:50 [mmerrell]
jgraham: 16:30 should start Shadow DOM discussion
02:09:05 [mmerrell]
jgraham: first thing Friday will be long-running session
02:10:29 [mmerrell]
simonstewart: Custom Selectors will be a 30 minute discussion
02:11:06 [zcorpan]
zcorpan has joined #webdriver
02:12:12 [AutomatedTester]
https://docs.google.com/document/d/1gUm7Be-akW2-4mjr15cnZlzwoAfOlfL7b3tWCDrb1Jg/edit#
02:13:41 [mmerrell]
Boaz: there is interest in creating bi-directional communication functionality added to the spec
02:13:55 [mmerrell]
AutomatedTester: 3 elements: use cases, transports, APIs
02:14:06 [mmerrell]
AutomatedTester: this is not standardizing on CDP, this is faciilitating test automation
02:14:24 [mmerrell]
AutomatedTester: frame use cases around that principle, we wont' get bogged down in historical implementations
02:14:33 [mmerrell]
AutomatedTester: focus on what this group needs for a bi-di tool
02:15:05 [mmerrell]
AutomatedTester: starting with use cases, we have input from Sauce Labs and others
02:15:07 [JohnJansen]
https://mit.webex.com/mit/j.php?MTID=mf0c6a95eedfa61b9e4d6dbdc08e3798a
02:15:14 [simonstewart]
q+
02:15:19 [simonstewart]
q?
02:15:24 [mmerrell]
jgraham: [explains how to use the queue for speakers]
02:15:34 [JohnChen]
q+
02:15:52 [cb]
q+
02:15:55 [AutomatedTester]
q?
02:16:01 [jgraham]
ack simonstewart
02:16:01 [mmerrell]
q?
02:16:22 [mmerrell]
simonstewart: use cases: people use Cypress and Puppeteer in certain ways that should inform this feature
02:16:31 [mmerrell]
simonstewart: the ability to wait for an event in the DOM
02:16:43 [mmerrell]
simonstewart: being notified of those events allows stable tests
02:16:53 [mmerrell]
simonstewart: logging what's going on in the browser, including console and JS errors
02:17:23 [mmerrell]
simonstewart: people really like to fail tests on ANY JS error, which they do by loading a page and executing a script, but which can cause race conditions
02:17:36 [mmerrell]
simonstewart: also, stubbing out back-ends
02:18:02 [mmerrell]
simonstewart: people are trying to record traffic, then simulate the back-end operations. Supporting that woul dhelp
02:18:14 [mmerrell]
simonstewart: CDP gives you a full-page screenshot option
02:18:21 [jgraham]
ack JohnChen
02:18:23 [mmerrell]
simonstewart: [4 use cases total]
02:18:39 [mmerrell]
JohnChen: people like the features of Puppeteer, and want those features in WebDriver
02:19:10 [mmerrell]
JohnChen: e.g. intercepting HTTP requests, and modifying them dynamically
02:19:28 [mmerrell]
CalebRouleau: is that the same as Simon's point about stubbing back-end requests
02:19:34 [mmerrell]
jgraham: it's the same thing
02:19:43 [simonstewart]
It's a better formulation of what I said
02:19:58 [mmerrell]
JohnChen: users need to be able to get notified without having to poll the page
02:20:03 [AutomatedTester]
q?
02:20:10 [jgraham]
ack cb
02:20:51 [mmerrell]
cb: at Sauce Labs, we have the ability to bypass the crhomedriver, which allows us to allow custom commands (throttling CPU, simulating performance issues, etc)
02:21:41 [jgraham]
q+
02:21:47 [mmerrell]
cb: SL performance product also requires these internal accesses, and incorporating that ability into the protocol would help greatly
02:22:09 [AutomatedTester]
ack jgraham
02:22:12 [mmerrell]
cb: meaningful error messages, access to internal devtool protocols, all would be helpful for customers to be able to write better tests
02:22:53 [mmerrell]
jgraham: is it important to SL that you can get the same profiling data out of all browsers, or can these things be more browser-specific?
02:23:14 [mmerrell]
jgraham: FF has different data from Chrome, which greatly complicates the possibility to do this
02:23:30 [mmerrell]
cb: we just need to get the same kind of information, understanding that it will be different
02:23:38 [AutomatedTester]
q?
02:23:52 [mmerrell]
cb: we need to get as much information about the AUT as possible, no matter how we can get it (page load timings, logs, etc)
02:24:18 [mmerrell]
jgraham: for these introspection APIs, these use cases *are* satisfied even though there isn't uniformity among the browsers
02:24:18 [ato]
q+
02:24:22 [AutomatedTester]
ack ato
02:24:22 [jgraham]
ack ato
02:24:41 [mmerrell]
ato: one more use case: from WPT, a question came up
02:25:16 [mmerrell]
ato: in order to be able to write good tests for the browsers, functionality could be exposed in this manner that would help browser developers as well as end users
02:25:20 [AutomatedTester]
rrsagent, this meeting spans midnight
02:25:41 [mmerrell]
jgraham: do you mean event-based user interactions?
02:26:52 [mmerrell]
ato: there's an interest from spec authors who want to expose bi-di APIs, which is currently made difficult by WebDriver
02:27:23 [mmerrell]
jgraham: there are other contraints here: some of these "mocking" features are very difficult to implement in terms of a command-response protocol
02:28:09 [ato]
q?
02:28:10 [mmerrell]
Boaz: I've invited Reilly [from the Chrome team] to discuss this particular thing Friday afternoon
02:28:34 [mmerrell]
Boaz: this will allow us to state these use cases to one of the most important stakeholders
02:28:35 [cb]
q+
02:29:05 [mmerrell]
jgraham: to ato: is this for developer ergonomics for the browser developers, or are they being prevented from developing these things?
02:29:45 [mmerrell]
ato: one example is the Gutenberg project, which is a test suite--this should be used as a target for the kinds of features being asked for
02:30:00 [jgraham]
https://github.com/WordPress/gutenberg/tree/master/packages/e2e-tests/specs
02:30:27 [mmerrell]
ato: the test suite isn't doing anything particularly challenging, but it would be a different programming model. There's a desire from modern web developers to have an API that allows async comms
02:30:30 [simonstewart]
q+
02:30:59 [mmerrell]
ato: the one thing the test suite does, where WD would be helpful, is in the cases of complicated keyboard interactions
02:31:09 [mmerrell]
ato: these cases woul dbe better expressed in WebDriver
02:31:23 [AutomatedTester]
q?
02:31:23 [mmerrell]
ato: it exposes and surfaces browser-specific interactions
02:31:26 [jgraham]
ack cb
02:32:00 [mmerrell]
cb: for SL customers, bi-di mechanism would allow for much better state management of tests
02:32:08 [AutomatedTester]
q?
02:32:09 [mmerrell]
simonstewart: that's risky, because so many things can go wrong
02:32:39 [mmerrell]
cb: agreed, but those things that can go wrong are commonly network-based
02:33:43 [mmerrell]
ato: another use case: people writing clients for automation could benefit from other features, e.g. dynamic changes to iFrame or documents
02:34:04 [mmerrell]
ato: these events are important when writing clients
02:34:38 [mmerrell]
ato: another use is performance logs: people need to know about the performance logs for internal timings
02:34:53 [mmerrell]
ato: these things are inherently browser-specific, and they already exist
02:35:01 [mmerrell]
AutomatedTester: moving on, to simonstewart
02:35:03 [jgraham]
ack simonstewart
02:35:56 [mmerrell]
simonstewart: summary of use cases: log (performance, console, javascript errors), network interception, and stubbing out req/res, mutation/observation in waiting for events or new contexts
02:36:39 [ato]
q+
02:36:48 [mmerrell]
jgraham: we should not assume this is the complete set of use cases, and we should get more data from other tooling
02:37:07 [mmerrell]
Boaz: we should also consider web-USB and others
02:37:34 [mmerrell]
Boaz: as well as mutation/observation of non-browser features, e.g. Geolocation
02:37:49 [mmerrell]
ato: these things are not dependent on a bi-di comm interfact
02:37:58 [AutomatedTester]
q?
02:38:06 [mmerrell]
CalebRouleau: there is probably overlap of these use cases
02:38:11 [AutomatedTester]
ack ato
02:39:05 [mmerrell]
simonstewart: bi-di comms expose 2 common patterns: 1 request, I want 1 response, or "I'm registering a listener, so give me responses as they come up"
02:39:21 [mmerrell]
simonstewart: registering for a listener is "network interception"
02:39:44 [mmerrell]
simonstewart: e.g. "I want to click a button" or "I want to type something"
02:40:13 [mmerrell]
simonstewart: people usually set up a web socket as a long-running connection (usually on localhost only)
02:40:26 [mmerrell]
simonstewart: this normally sets up the web socket
02:40:47 [mmerrell]
simonstewart: when not on localhost, we introduce risks around corporate networks
02:40:47 [jgraham]
q+
02:40:48 [ato]
q+
02:41:15 [JohnJansen]
ack jgraham
02:41:21 [mmerrell]
simonstewart: need a mechanism for reconnecting and being notified of what was missed (in the case of complcated, corporate networks)
02:41:28 [JohnJansen]
rrsagent, make minutes
02:41:28 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html JohnJansen
02:41:34 [mmerrell]
jgraham: feels like a lot of scope creep in the context of what exists
02:41:53 [CalebRouleau]
q+
02:41:53 [mmerrell]
jgraham: buffering up these things won't work well. Listening to network requests adds risk
02:42:20 [mmerrell]
jgraham: timeouts are a risk
02:42:53 [mmerrell]
jgraham: need to hear that this is super-important from the most prolific users before we make the browser responsible for caching all these requests
02:43:20 [mmerrell]
cb: the VM will shut down if the request times out
02:43:23 [brrian]
q+
02:43:55 [mmerrell]
jgraham: is network flakiness such a big problem that we need to later the protocol? do we need to abstract over that with an event buffer to keep the integrity of the comms in place to that extent?
02:44:07 [mmerrell]
cb: we can always build an abstraction around it that doesn't need to be part of the protocol
02:44:12 [simonstewart]
q+
02:44:37 [brrian]
q-
02:44:59 [mmerrell]
jgraham: not sure about the web socket issue, but would like to know whether this body considers that to be a risky or unstable thing to rely on
02:45:10 [mmerrell]
simonstewart: HTTP2 server is an alternative
02:45:18 [simonstewart]
Server push
02:45:29 [simonstewart]
q?
02:45:34 [jgraham]
ack ato
02:45:41 [mmerrell]
MikeSmith: WebSockets are essentially deprecated at this point
02:45:55 [AutomatedTester]
s/HTTP2 server/HTTP2 server push/
02:45:56 [AutomatedTester]
q?
02:46:24 [mmerrell]
ato: we are jumping ahead of the discussion - many assumptions going on about how the protocols work
02:46:46 [mmerrell]
ato: we've agreed that having a bi-di mechanism is good, but we are constrained by the existing protocols that are out there
02:46:59 [mmerrell]
ato: designing a new one from scratch seems silly
02:47:38 [mmerrell]
ato: I'd like to see a good x-browser automation protocol, designed from scratch, which covers all use cases, which fixes the problems in the existing protocols, but that's not possible at this point
02:48:29 [mmerrell]
ato: SL says they want to expose the existing internals (CDP/Puppeteer, etc), but not all these protocols would support the kind of embedding necessary for the "resumption of session" that simonstewart wanted
02:48:55 [mmerrell]
simonstewart: one of the problems we had developing the WD standard is the constant improvement/change we had during the process
02:49:09 [cb]
q+
02:49:13 [AutomatedTester]
q?
02:49:13 [mmerrell]
jgraham: I believe SL didn't say they wanted those features--they're already doing them
02:49:39 [mmerrell]
ato: this isn't about CDP specifically, even though that's what it sounds like when I listen to this body
02:50:15 [mmerrell]
ato: CDP does support session resuming, web socket connections, etc... by going in to that conversation, we're jumping ahead... we're adding constraints
02:50:29 [jgraham]
q+
02:50:32 [Boaz]
q?
02:50:35 [mmerrell]
ato: I would like to know the opinions of the browser vendors to know what the outcome should be
02:50:39 [Boaz]
q+
02:50:46 [simonstewart]
q-
02:51:03 [jgraham]
ack CalebRouleau
02:51:09 [mmerrell]
ato: need more clarity as to what exactly would be *in* that web socket, if the web socket is exposed
02:51:18 [mmerrell]
CalebRouleau: we want to think about what's currently there with CDP
02:51:54 [brrian]
q+
02:52:08 [mmerrell]
CalebRouleau: we don't want to implement something from scratch in the Chrome Team. We've worked for a long time on the CDP, and need the new feature set to be at least somewhat compatible with what we've done already
02:52:49 [mmerrell]
CalebRouleau: we don't want WD to be overly complicated
02:52:57 [AutomatedTester]
q?
02:53:00 [mmerrell]
simonstewart: we should take the caching of things off the table for now
02:53:26 [JohnJansen]
+1 to simonstewart taking caching off the table
02:53:49 [mmerrell]
drousso: Apple's position is that we want to see how this will work before we sign off. Whether it's WebSocket or HTTP2, it's a rewrite for us
02:53:52 [CalebRouleau]
s/We've worked for a long time on the CDP/we have a lot of stuff that already depends on CDP and we don't want to support both/
02:54:02 [mmerrell]
drousso: so if we're going to do it, we need to know more before we can commit
02:54:18 [mmerrell]
jgraham: are you saying you're interested, but with no plans to implement?
02:54:47 [mmerrell]
brrian: we don't currently allow for either Web Sockets or HTTP2, and this would represent a significant spending of resources
02:55:00 [AutomatedTester]
q?
02:55:05 [mmerrell]
CalebRouleau: how does the CDP work for Safari, in detail?
02:55:20 [mmerrell]
simonstewart: the Safari implementation of the debug protocol is currently locked down
02:55:40 [AutomatedTester]
q?
02:55:44 [mmerrell]
CalebRouleau: I'm trying to ask what is publicly available, but it sounds like it's basically nothing
02:56:14 [mmerrell]
brrian: we need specific questions and specific feature requests in order to get this conversation going for Safari
02:56:49 [Hexcles]
RRSAgent, make minutes
02:56:49 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html Hexcles
02:56:59 [mmerrell]
jgraham: at some point we need a clear decision about the debug protocol, some entry criteria... but as long as we can agree on the messaging itself, that will be sufficient
02:57:20 [AutomatedTester]
q?
02:57:35 [jgraham]
ack cb
02:57:43 [AutomatedTester]
scribenick: AutomatedTester
02:58:12 [AutomatedTester]
cb: the SL major use case is being able to access the browser internals to surface that to people
02:58:41 [AutomatedTester]
CalebRouleau: you dont care the transport, you just want access
02:58:44 [AutomatedTester]
cb yes
02:58:48 [JohnJansen]
s/SL/SauceLabs
02:58:48 [AutomatedTester]
q?
02:58:56 [AutomatedTester]
ack jgraham
03:00:09 [AutomatedTester]
jgraham: for Mozilla we think there is a cross browser automation protocol that facilitates automation. We need to be aware that there is a move to something like puppeteer is a threat tot he web since it only covers 1 browser
03:00:23 [Hexcles]
s/ SL / SauceLabs /g
03:00:23 [AutomatedTester]
s/tot he/to the/
03:00:50 [bwalderman]
q+
03:01:06 [CalebRouleau]
q?
03:01:11 [ato]
q+
03:01:13 [CalebRouleau]
q+
03:01:18 [JohnChen]
q+
03:01:33 [simonstewart]
q+
03:01:52 [AutomatedTester]
jgraham: There has been some discussion around CDP for reuse. One of the historic complaints is that CDP is unstble and only gives us certain things that are chrome specific. We would need to see what is stable and what we can solve those
03:02:05 [AutomatedTester]
simonstewart: and this is why we focused on use cases
03:02:23 [simonstewart]
q?
03:02:29 [Boaz]
ack boaz
03:02:43 [AutomatedTester]
JohnChen: yes, my point is that there are implicit stability from the APIs that use CDP
03:02:58 [AutomatedTester]
s/JohnChen/jgraham
03:04:34 [AutomatedTester]
q?
03:04:48 [jgraham]
ack brrian
03:05:40 [AutomatedTester]
brrian: it would be great to expose the API and just add to it. That is a bad idea. We need to make sure that we versioning and even with that we break things all the time.
03:06:34 [AutomatedTester]
brrian: it is very difficult to test at the moment
03:07:09 [AutomatedTester]
brrian: whatever we do needs to make sure is testable and that we dont rely on browser internals
03:07:54 [AutomatedTester]
brrian: in webkit we have processes that come and go and our tools should not have to follow that
03:08:21 [AutomatedTester]
... we are going to need some compat layer to figure this out.
03:09:26 [AutomatedTester]
... [discusses examples of where webdriver and a tool might look different]
03:09:29 [AutomatedTester]
q?
03:10:06 [AutomatedTester]
brrian: as for JSON RPC, we have used it for 11 years and it is solid so I dont think we need to change that
03:10:26 [JohnJansen]
q?
03:11:05 [karl]
karl has joined #webdriver
03:11:23 [AutomatedTester]
jgraham: is this very different to what the chrome engineers have said ?
03:11:39 [AutomatedTester]
brrian: no, this is not going to be a lot of work, its just going to be well tested
03:12:28 [AutomatedTester]
drousso: one of the things that I would caution against. A lot of things have browser leakage and we need to make sure that browser impl info is not bled out
03:13:02 [simonstewart]
q?
03:13:04 [AutomatedTester]
CalebRouleau: there are lot of issues, like site allocation, we need to make we are a level above that
03:13:18 [AutomatedTester]
ack bwalderman
03:13:23 [CalebRouleau]
s/site allocation/site isolate/
03:13:52 [AutomatedTester]
bwalderman: we need to work top down from use cases like brrian suggested
03:14:17 [AutomatedTester]
... and it might be better to keep them separate from the debug protocols out there
03:15:06 [CalebRouleau]
q?
03:16:15 [brrian]
q+
03:17:43 [AutomatedTester]
AutomatedTester: are you suggesting 2 connections into the browser or that the shim would handle 2 and then do magic into the browser
03:17:59 [AutomatedTester]
bwalderman: it would be in the shim
03:18:18 [AutomatedTester]
AutomatedTester: good as there could be an attack vector into the browser if there are 2 and we need to be aware
03:18:52 [AutomatedTester]
jgraham: ok but we need to make sure that the connection can handle that
03:19:06 [AutomatedTester]
... and that the shaping of packets can handle it
03:20:15 [AutomatedTester]
... we have seen in gecko that there are cases where this doesnt work. We are constrained on what the low level remote protocols can handle.
03:20:33 [AutomatedTester]
bwalderman: I am not suggesting that we write from scratch
03:20:39 [CalebRouleau]
q?
03:20:39 [AutomatedTester]
q?
03:20:50 [AutomatedTester]
ack ato
03:25:36 [AutomatedTester]
ato: is it reasonable to have something that maps down to other protocol?
03:25:42 [karl]
Context about what ato is saying http://operasoftware.github.io/scope-interface/
03:25:42 [karl]
https://dev.opera.com/blog/opera-scope-protocol-specification-released/
03:26:30 [AutomatedTester]
... we have seen multiple versions and there has been times to standardise
03:26:54 [AutomatedTester]
... we need to make sure we agree on what protocol actually means and transport layer actual means
03:27:04 [AutomatedTester]
q?
03:27:53 [jgraham]
ack CalebRouleau
03:27:56 [jgraham]
ack JohnJansen
03:27:56 [AutomatedTester]
CalebRouleau: the new devtools team are interested in standards
03:28:03 [jgraham]
ack JohnChen
03:28:12 [jgraham]
Zakim: close the queue
03:28:35 [AutomatedTester]
JohnChen: we have been experimenting with webdriver and upgrade to a bidi connection via CDP
03:28:43 [jgraham]
close the queue
03:29:19 [simonstewart]
q?
03:29:27 [simonstewart]
q-
03:30:53 [AutomatedTester]
brrian: as far as 2 protocols... for security... we have already 2 and they enter the stack at 2 different points.
03:31:13 [AutomatedTester]
... we have mechanisms to protect the user now
03:31:58 [AutomatedTester]
... [explains how a bad actor could attack]
03:32:12 [karl]
things from the past https://github.com/WICG/devtools-protocol
03:32:59 [AutomatedTester]
... and there are people writing a lot of adaptors for VSCode and they dont think that it is a lot of work
03:33:04 [Hexcles]
RRSAgent, make minutes
03:33:04 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html Hexcles
03:33:05 [AutomatedTester]
LUNCH
03:33:51 [Hexcles]
Hexcles has joined #webdriver
03:35:14 [Hexcles]
Hexcles has joined #webdriver
04:02:53 [zcorpan]
zcorpan has joined #webdriver
04:08:49 [Hexcles]
Hexcles has joined #webdriver
04:27:08 [bwalderman]
bwalderman has joined #webdriver
04:28:24 [diemol]
diemol has joined #webdriver
04:30:49 [titusfortner]
titusfortner has joined #webdriver
04:31:14 [zghadyali]
zghadyali has joined #webdriver
04:31:33 [Hexcles]
Hexcles has joined #webdriver
04:31:45 [jgraham]
reopen the queue
04:34:55 [CalebRouleau]
CalebRouleau has joined #webdriver
04:36:16 [mmerrell]
mmerrell has joined #webdriver
04:40:43 [drousso]
drousso has joined #webdriver
04:44:29 [Hexcles]
https://gist.github.com/Hexcles/69f44b94aa616981a564efff11e5f4bb
04:48:43 [mmerrell]
jgraham: change in the agenda
04:48:49 [mmerrell]
scribenick: mmerrell
04:48:51 [karl]
karl has joined #webdriver
04:49:11 [mmerrell]
jgraham: move the continuing discussion about bi-di to Friday morning
04:49:34 [JohnJansen]
https://docs.google.com/document/d/1eJx437A9vKyngOQ49lYYD3GspDUwZ6KpKDgcE2eR00g/edit
04:49:38 [mmerrell]
jgraham: homework needs to be done, where Google team proposes beginnings of an outline for the bi-di protocol
04:50:01 [mmerrell]
CalebRouleau: it's not clear that we should start with load event--we should start with something else in order to satisfy the 3 other use cases
04:50:19 [stevenb]
stevenb has joined #webdriver
04:50:41 [mmerrell]
simonstewart: one clear thing is that we're going to re-hash bi-di on top of WD, which won't satisfy all needs
04:51:16 [mmerrell]
... need to put building blocks in place to move forward
04:51:29 [simonstewart]
simonstewart has joined #webdriver
04:51:33 [simonstewart]
present+
04:51:40 [simonstewart]
present+
04:51:42 [mmerrell]
CalebRouleau: to JohnChen: could you write up a proposal
04:51:45 [simonstewart]
present+
04:52:10 [mmerrell]
JohnChen: today, you can't do these use cases with WD, but you can do some amount of "loading"
04:52:40 [mmerrell]
simonstewart: agree with jgraham: this will allow the network proposal to move forward
04:53:02 [mmerrell]
CalebRouleau: maybe simonstewart can come up with the network proposal while Google team works with jgraham to work on a proposal for Loading
04:53:13 [mmerrell]
jgraham: the loading proposal will look like CDP without the target stuff
04:53:23 [mmerrell]
jgraham: "how do I address a loading context?"
04:53:34 [urata]
urata has joined #webdriver
04:53:37 [mmerrell]
jgraham: not everyone has to participate in the side meeting, but it should be open
04:54:04 [mmerrell]
jgraham: if we're not making progress on loading, we can address later
04:54:06 [nao_watanabe_access]
nao_watanabe_access has joined #webdriver
04:54:22 [mmerrell]
AutomatedTester: moving bi-di discussion to Friday morning. Agenda has been updated
04:54:43 [CalebRouleau_]
CalebRouleau_ has joined #webdriver
04:55:03 [mmerrell]
AutomatedTester: need to start with custom selector strategies, then shadow DOM, then break, then ARIA driver, then the laundry list of other items on the list
04:55:15 [mmerrell]
AutomatedTester: (the non-contentious ones)
04:55:27 [mmerrell]
[general assent ensued]
04:55:33 [jgraham]
topic: Custom selector strategies
04:55:50 [mmerrell]
AutomatedTester: from cb: custom selectors
04:56:10 [mmerrell]
cb: objective is to help user of WD protocol to automate tests for new frameworks like React/Vue
04:56:44 [mmerrell]
cb: friction is that new frameworks are built on browser features that aren't mapped well to WebDriver element locators
04:57:14 [mmerrell]
cb: automation engineers are having trouble getting to some of these new kinds of elements. Protocol needs to be extended to help locate these kinds of elements
04:57:15 [jgraham]
q?
04:57:21 [jgraham]
ack brrian
04:58:06 [jgraham]
q+
04:58:24 [mmerrell]
cb: 2 proposals: drivers can share libraries of atoms. WDio can fetch elements by property name or by component property, taking advantage of shared components in new frameworks. Risk is that this creates organizational overhead for application teams
04:58:41 [titusfortner]
q+
04:59:06 [simonstewart]
q+
04:59:38 [mmerrell]
cb: other option is "custom selector strategy", allowing vendors to be able to intercept selectors and be smarter about actually locating the element. Advantage here is that there's no new work for this body. Downside is that implementations could be so different that there's more overhead for browser vendors, and behavior won't be standardized
05:00:28 [mmerrell]
... alternative is that users could register scripts that would collate and cache selectors and selector scripts to avoid unnecessary wire calls
05:01:01 [ato]
q
05:01:02 [ato]
q+
05:01:07 [mmerrell]
titusfortner: this would allow the driver to operate much more quickly. TestCafe allows location by component, not just CSS. Don't know about implementation, but we need to know if all browsers work the same wrt WDio?
05:01:08 [diervo]
diervo has joined #webdriver
05:01:22 [mmerrell]
cb: yes it does--the abstraction goes through the virtual DOM
05:01:25 [AutomatedTester]
q?
05:01:31 [jgraham]
ack jgraham
05:01:33 [titusfortner]
q-
05:01:35 [diervo]
present+
05:01:48 [JohnJansen]
rrsagent, make minutes
05:01:48 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html JohnJansen
05:01:53 [AutomatedTester]
q?
05:02:28 [mmerrell]
jgraham: bad idea to try to standardize on large chunks of JS atoms. it's not something that will be future-proof: web frameworks come and go, and standardized javascript ends up being brittle
05:03:18 [mmerrell]
jgraham: we should either double-down on vendor-specific extensions to the protocol, or register JS scripts (caching) to improve performance
05:04:01 [simonstewart]
q?
05:04:05 [mmerrell]
titusfortner: this wouldn't be limited to just locators--it could be any javascript
05:04:09 [mmerrell]
cb: yes, it could be
05:04:17 [AutomatedTester]
q?
05:04:27 [mmerrell]
ato: question: can you explain why this is needed?
05:04:44 [mmerrell]
... do you mean to register particular methods?
05:04:48 [mmerrell]
cb: yes
05:05:03 [mmerrell]
ato: these frameworks manipulate the DOM in a way that makes it difficult to just use CSS selector?
05:05:48 [mmerrell]
cb: yes--React developers write these components using more dynamic logic, and the QA engineer has trouble defining the locator
05:05:55 [jgraham]
ack simonstewart
05:06:11 [mmerrell]
titusfortner: but it's not the QA eng we're concerned with. This is for developers
05:06:34 [titusfortner]
q+
05:07:48 [mmerrell]
simonstewart: there's something here, about registering javascript snippets, which would return a handle. Use cases: good points about React and Vue, compiled and inflated, produced by the client and uploaded. New "friendly" locators in Selenium as well as Watir's JS atoms, all upload these snippets, which becomes chatty and expensive really quickly
05:08:02 [drousso]
q?
05:08:03 [drousso]
q+
05:08:20 [mmerrell]
simonstewart: you don't want to inject these scripts on every page load--we want to do this per-session. This would amount to an overloaded version of the JavascriptExecutor
05:08:47 [mmerrell]
simonstewart: the user-facing API would make it look like a selector, but underneath it's using the same handler, parameterized
05:09:13 [mmerrell]
simonstewart: this will end up being a client concern--not a WD spec concern
05:09:28 [mmerrell]
simonstewart: this will be hard to spec out
05:09:32 [mmerrell]
jgraham: it won't be that hard
05:10:51 [AutomatedTester]
ack ato
05:11:32 [diervo]
q?
05:11:43 [mmerrell]
ato: the latter proposal isn't too invasive--it makes sense to register scripts and allow devs to inject a JS library and re-use it per-session, but these solutions are so different that they address different problems
05:11:56 [mmerrell]
ato: the selector API needs to be locked down very tightly
05:12:02 [jgraham]
q+
05:12:52 [mmerrell]
ato: you'd want a capability to pre-register a selector and identify them by a string (the key in a hash), passed in the body of a function... it would be a wrapper accepting one argument, which would return the locator
05:12:52 [diervo]
q+
05:13:04 [AutomatedTester]
ack titusfortner
05:13:32 [cb]
q+
05:13:35 [mmerrell]
titusfortner: is there a distinction between using a custom selector and pre-registering the scripts? how generic is the current mechanism?
05:14:20 [mmerrell]
titusfortner: should we have a generic "driver registration", and then have a component-based registry, all as part of the spec?
05:14:21 [bwalderman]
q+
05:14:41 [mmerrell]
simonstewart: if you have this registry for any of the javascript, you could use it for any of these use cases
05:14:54 [mmerrell]
titusfortner: would it make sense to explicitly make it generic?
05:15:16 [mmerrell]
simonstewart: you want the remote end to be able to have non-Javascript locators
05:15:40 [mmerrell]
simonstewart: Jason Arbon demonstrated an ML-based element locator that wasn't Javascript
05:15:53 [mmerrell]
simonstewart: but in most cases it will be JS
05:16:02 [mmerrell]
jgraham: we should pin this down to stuff that can be implemented in JS
05:16:07 [mmerrell]
simonstewart: yes, agreed
05:16:42 [ato]
q+
05:18:00 [mmerrell]
jgraham: we shouldn't allow scope creep, with all that's going on, to include non-JavaScript features into the "pinning" (registering) piece we're talking about
05:18:14 [AutomatedTester]
ack drousso
05:18:25 [simonstewart]
q+
05:18:27 [jgraham]
q-
05:18:30 [JohnChen]
q+
05:18:34 [mmerrell]
drousso: fundamentally, this isn't about pinning or caching--it's minimizing the chattiness of the comms
05:19:25 [mmerrell]
... this isn't fundamentally a concern of the WebDriver spec. This is about implementation, and adding this to the spec would add more questions and opens the door for complications
05:19:31 [AutomatedTester]
q?
05:19:32 [mmerrell]
q?
05:20:01 [gsnedders]
RRSAgent, make minutes
05:20:01 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html gsnedders
05:20:22 [AutomatedTester]
ack diervo
05:20:26 [mmerrell]
diervo: we have a huge group of web components. From our POV, we shouldn't worry about the spec for locators, we should be able to register anything before the session
05:20:50 [mmerrell]
... having this ability would foster custom elements, and would allow for advanced traversal, etc.
05:21:30 [mmerrell]
... we would like syntactic sugar for being able to select things with custom commands
05:21:31 [AutomatedTester]
q?
05:21:39 [jgraham]
ack cb
05:21:39 [AutomatedTester]
ack cb
05:21:40 [mmerrell]
simonstewart: this is, at its heart, JavaScript, though, right?
05:21:43 [mmerrell]
diervo: yes
05:22:26 [JohnJansen]
present+
05:22:26 [mmerrell]
cb: this proposal fosters the sharing of code, even when items are embedded in the code and in different places. This would allow shareable atoms
05:22:51 [mmerrell]
drousso: but you can already do that--you don't need to change the spec in order to make this happen. You can code it elsewhere
05:23:08 [ato]
q?
05:23:11 [brrian]
q+
05:23:19 [mmerrell]
simonstewart: there's a difference between what browser developers need and what execution vendors need
05:23:40 [CalebRouleau_]
q+
05:24:49 [AutomatedTester]
ack bwalderman
05:25:03 [mmerrell]
[fast discussion about caching, sandboxing, bootstrapping ensues, from which no point arose]
05:25:29 [mmerrell]
bwalderman: if we're going to add this ability, we should also allow messages to pass between the client and the script
05:26:00 [jgraham]
ack ato
05:26:05 [mmerrell]
... it would be interesting to register these events. It would help users, but is a little outside the scope of custom selectors
05:26:26 [mmerrell]
... it's more in the scope of the bi-di discussion
05:26:34 [cb]
q+
05:27:03 [mmerrell]
ato: there's an alternative to consider--JS frameworks are sensitive to DOM modification [gives examples]
05:28:05 [mmerrell]
... there's risk in registering these snippets to the global window. It could result in race conditions (?) and other issues with dynamic changing of page contents when multiple regions of the page are affected
05:28:08 [titusfortner]
q+
05:28:50 [titusfortner]
q-
05:29:22 [mmerrell]
jgraham: qq: the proposal was to dump text into a map, which you can then later pull it out... the proposal was not to have live JS scripts executing at will within the browser. This would present a large interaction/security risk. The intent is to optimize performance, not to enhance feature function or to execute scripts different than is currently done
05:29:31 [titusfortner]
q+
05:30:13 [karl]
karl has joined #webdriver
05:30:19 [mmerrell]
ato: not quite--the concern was about maintainability of these functions. The client should be able to pre-register a function, but the concern is that there will be a maintenance burden
05:30:56 [mmerrell]
ato: maybe the browser could be pre-loaded with a webdriver running?
05:31:05 [AutomatedTester]
q?
05:31:47 [mmerrell]
cb: if we could pin these JS snippets to the session, we could provide these features easily. SL customers would benefit from these features, both for performance purposes as well as test stability
05:31:57 [mmerrell]
ato: wouldn't it be better if the React devs owned the selector?
05:32:13 [mmerrell]
cb: that's not important--we just need to be able to support the feature?
05:32:41 [mmerrell]
ato: it's not future-proof--old versions of React won't work the same way as current ones, and that will be a continuing risk to any project implementing this
05:32:45 [mmerrell]
simonstewart: agreed
05:32:56 [mmerrell]
jgraham: we shouldn't be discussing SL product strategy here
05:33:00 [ato]
q?
05:33:04 [mmerrell]
simonstewart: but pinning a script still makes sense
05:33:07 [ato]
ack simonstewart
05:33:11 [cb]
q-
05:33:54 [mmerrell]
simonstewart: it's a useful feature, which could be implemented in many ways... as a bootstrap script, this would alter the AUT, but it could also be put into the driver process, and that would allow better performance
05:34:04 [mmerrell]
simonstewart: you need 2 endpoints: upload and call
05:34:09 [mmerrell]
jgraham: we already have call
05:34:28 [AutomatedTester]
q?
05:34:37 [mmerrell]
jgraham: call could be used for this
05:34:47 [mmerrell]
titusfortner: what's the downside of having another endpoint?
05:35:06 [AutomatedTester]
ack JohnChen
05:35:08 [JohnJansen]
isn't this the proposal?
05:35:08 [JohnJansen]
https://docs.google.com/document/d/13ycIhXJxoCq0K6ti10VpFp_l9hLtTFrx941uC_aSwfk/edit
05:35:33 [mmerrell]
simonstewart: we shouldn't need another endpoint--but anyway, we're arguing over how much it will cost, not whether or not we need it, so it sounds like we've made our decision
05:35:56 [cb]
q+
05:35:59 [simonstewart]
That proposal needs clearing up to talk about script pinning
05:36:24 [mmerrell]
JohnChen: this script will still need to be send to the app, no matter what. There might not be a real way, at least in chrome, to pin these scripts in a way that will be markedly improved wrt performance
05:37:15 [mmerrell]
JohnChen: the selector pinning strategy as proposed will be exceedingly difficult to implement due to how the already-huge chunks of JS are stored in Chrome
05:37:43 [mmerrell]
JohnChen: we can store these snippets, but it will be difficult, and it won't help that much
05:38:00 [mmerrell]
jgraham: this would supplant the existing JS around "findElement"
05:38:21 [AutomatedTester]
q?
05:39:13 [mmerrell]
JohnChen: not in every case. It varies depending on how many elements you're looking for, and where they're located in relation to each other. There's a way to do this, but we shouldn't try to merge this with existing findElement--we should offer a mechanism for uploading JS that would replace it
05:39:38 [mmerrell]
titusfortner: this might not need to be part of the spec
05:40:08 [Hexcles]
s/send to the app/sent to Chrome/
05:41:03 [jgraham]
ack brrian
05:41:14 [mmerrell]
brrian: if these atoms are used in testing, and used in the app, can't the app include a snippet that would "assist" with locating the element?
05:41:32 [AutomatedTester]
q?
05:42:02 [mmerrell]
simonstewart: quite often people minify their JS, which mangles the ability for the app to display the same element that is stored in the app
05:42:27 [diervo]
q?
05:42:34 [mmerrell]
simonstewart: testers are usually separate from the developers and have no influence there
05:43:24 [mmerrell]
simonstewart: testers can't have the locators changed to something more friendly
05:43:45 [mmerrell]
mmerrell: the wall between devs and testers is the norm, not the exception
05:44:05 [AutomatedTester]
scribenick: AutomatedTester
05:44:21 [AutomatedTester]
brrian: this is not going to make things faster
05:44:25 [CalebRouleau_]
q?
05:44:38 [AutomatedTester]
titusfortner: yes but this is for larger connections we are sending lots of data all the time
05:44:41 [brrian]
... from safaridriver onward (to devices, other apps, etc)
05:46:13 [AutomatedTester]
brrian: why are we caring about people perf, they should
05:46:15 [ato]
q?
05:46:18 [ato]
q+
05:46:45 [AutomatedTester]
titusfortner: well a lot of people are doing things that are silly like they are sending 20 commands for finding 1 element
05:47:24 [titusfortner]
q-
05:47:26 [cb]
q-
05:47:53 [jgraham]
ack CalebRouleau_
05:47:57 [AutomatedTester]
ACTION: Saucelabs to write a propsal and send to the group
05:48:19 [AutomatedTester]
q?
05:48:22 [ato]
q-
05:48:30 [ato]
CalebRouleau: ++
05:48:48 [AutomatedTester]
Topic: ShadowDOM Support
05:49:53 [jgraham]
q+
05:49:57 [AutomatedTester]
https://github.com/w3c/webdriver/pull/1320
05:50:02 [ato]
ScribeNick: ato
05:50:09 [ato]
AutomatedTester: We have discussed this before, briefly.
05:50:09 [brrian]
👆
05:50:34 [ato]
... I had a proposal in a PR from before.
05:50:36 [ato]
... We need to think of a process, and happy to throw away this PR and start from scratch.
05:50:41 [ato]
... Shadow DOM has interesting problems.
05:51:00 [ato]
... We need to be able to interact with it, and there are two types of nodes.
05:51:14 [ato]
... Sometime you can see into these nodes, and sometimes they operate as black boxes.
05:51:35 [ato]
... Frameworks like React are looking into using Shadow DOM, and we need to support this use case otherwise it will be hard to automate.
05:51:39 [AutomatedTester]
q?
05:51:41 [simonstewart]
cb: use "/msg" to send a private message :)
05:52:19 [ato]
jgraham: You have a shadow host element, which conceals a shadow DOM.
05:53:16 [ato]
... If you want to go into the shadow DOM.
05:53:44 [ato]
... Two shadow DOM host elements: open and closed.
05:53:56 [ato]
... Theoretically with open elements the inner elements are exposed to JS.
05:54:04 [ato]
... You can polyfill this today with JS.
05:54:27 [ato]
... You can Execute Script on the DOM property that gives you the shadow root, and from there you have access to the tree below that to manipulate them further.
05:54:35 [ato]
... My proposal is that we hoist that into a WebDriver endpoint.
05:54:46 [ato]
... Should should also work for closed shadow DOM trees.
05:55:01 [ato]
... If you want to pierce the encapslation field for testing, that is possible to do from content.
05:55:13 [ato]
... DevTools allows you to pierce it.
05:55:38 [ato]
... "element/shadow" could return a shadow host for that element.
05:56:11 [mmerrell]
s/encapslation/encapsulation/
05:56:48 [ato]
... The alternative is for Find Element to take an extra parameter: but instead of returning the element, it would return the shadow DOM root inside that element.
05:57:08 [ato]
lukebjerring: Can I see the original proposal?
05:57:20 [ato]
jgraham: The original proposal worked like frames, that you’d have to switch into the shadow DOM.
05:57:51 [ato]
jgraham: There are however a few things that work for frames that may not work for shadow DOM, so I don’t think it’s entirely workable.
05:58:00 [lukebjerring]
q+
05:58:17 [ato]
AutomatedTester: When you want to click on something, you need to make sure you’re in the right space.
05:58:33 [ato]
... For example, inside the <video> element you’d want the play button [element].
05:59:52 [ato]
diervo: At Salesforce we will soon have developers working on web components.
06:00:24 [ato]
... In Chrome and Safari it will throw when you click.
06:01:10 [ato]
jgraham: Why would you click on the shadow root element?
06:01:31 [pmdartus]
pmdartus has joined #webdriver
06:01:37 [ato]
diervo: You call a selector to find this, and people are sometimes confused.
06:01:50 [diervo]
rniwa
06:01:56 [jgraham]
present+ rniwa
06:02:15 [ato]
rniwa: Shadow DOM is a weird parallel tree.
06:02:28 [ato]
rniwa: It replaces the appearance of the shadow root element.
06:03:07 [ato]
rniwa: A click will pierce down to the right element inside the shadow DOM.
06:03:15 [ato]
rniwa: What will not work is elementFromPoint.
06:03:37 [ato]
rniwa: If you focus or click through the browser’s normal event queue things iwll work.
06:03:39 [AutomatedTester]
q?
06:03:50 [AutomatedTester]
ack jgraham
06:03:50 [jgraham]
ack jgraham
06:03:59 [AutomatedTester]
ack lukebjerring
06:04:09 [ato]
rniwa: What will not work is the JS primitives available to you as testing.
06:04:19 [ato]
s/as testing/for the test tools/
06:04:50 [ato]
lukebjerring: :next() selector on the shadow root is prone to bugs.
06:05:12 [ato]
... Does this proposal include prose on piercing the shadow DOM through CSS selectors?
06:05:14 [ato]
[?]
06:05:36 [ato]
... I.e. a parameter could define whether you want to pierce it.
06:05:48 [lukebjerring]
ack lukebjerring
06:05:49 [AutomatedTester]
https://github.com/w3c/webcomponents/issues/771
06:05:53 [ato]
rniwa: Historically there has been a proposal to have generic shadow-piercing combinators.
06:06:09 [ato]
rniwa: Every use of that was bad, especially for performance.
06:06:10 [jgraham]
q+
06:06:19 [ato]
rniwa: We don’t want to have this, was rejected by Google.
06:06:32 [ato]
rniwa: But _specifically_ for WebDriver you could consider having this.
06:07:00 [AutomatedTester]
ack jgraham
06:07:04 [ato]
rniwa: A :descendants() selector could potentially be made to pierce the tree, specifically for WebDriver.
06:07:44 [ato]
jgraham: Find Element From Element, where the root is the shadow DOM root element would be the easier option.
06:07:55 [ato]
jgraham: Implementing a new CSS selector is more work.
06:08:25 [pmdartus]
q+
06:08:40 [ato]
... There is utility to have WebDriver-only CSS selectors for use in e.g. Execute Script and CSS selectors, but we should take baby steps and do the thing that is easy to do today.
06:08:54 [AutomatedTester]
ack pmdartus
06:09:10 [ato]
pmdartus: We are facing huge, nasty shadow trees. Can go to the depth of eight levels.
06:09:14 [diervo]
https://gist.github.com/diervo/7ce4437bde4a382679b22306af9b5b6c
06:09:19 [ato]
... We have worked around this by using page objects.
06:09:37 [ato]
... You create abstraction that deals with the shadow DOM traversal for you.
06:09:51 [ato]
... This is more resilient than using a selector to one element within the shadow tree.
06:10:07 [ato]
... We see some value in the piercing shadow tree selector, but it wouldn’t be immediately applicable to us.
06:10:30 [diervo]
Here is out utility for shadow dom:
06:10:32 [ato]
Present+ gsnedders
06:10:32 [diervo]
https://gist.github.com/diervo/7ce4437bde4a382679b22306af9b5b6c
06:10:56 [stevenb]
stevenb has joined #webdriver
06:11:19 [ato]
lukebjerring: What I mean is that it could be solved from the client’s perspective much easier without WebDriver primitives.
06:11:29 [diervo]
q+
06:11:32 [AutomatedTester]
q?
06:11:43 [AutomatedTester]
q+
06:11:54 [ato]
... If you had shadow-piercing CSS selectors you could write compound selectors in your client code using helper functions.
06:11:57 [AutomatedTester]
ack diervo
06:12:24 [ato]
... Whereas other proposal here actually requires traversal.
06:13:08 [ato]
diervo: We trying to force our test authors to do the right thing rather than crafting very complicated XPath selectors.
06:13:19 [ato]
lukebjerring: Polymer translates basically to web components.
06:14:12 [ato]
diervo: Historically people have relied on a lot of relativty in their element queries.
06:14:24 [ato]
... This is fragile as the document structure changes and the component hierarchy changes.
06:14:39 [zcorpan]
zcorpan has joined #webdriver
06:14:49 [ato]
... We need to strike the right balance if we introduce a selector because it can be misused.
06:14:51 [AutomatedTester]
ack AutomatedTester
06:15:32 [ato]
rniwa: The shadow-piercing proposal in CSS 4 Selectors you can have a look at, but it forces you to define the boundaries of the shadow DOM.
06:15:42 [ato]
jgraham: They have something similar in the thing diervo posted.
06:15:55 [ato]
... The list of selectors thing is a thing we could implement in clients.
06:16:14 [ato]
... The fundamental primitive lacking from WebDriver, is, I have an element and select the shadow root of this element if it has one.
06:16:33 [ato]
... If there are more convenience APIs we can add in the future, then that is a second thing to build maybe later.
06:17:08 [ato]
diervo: Will this work for closed mode?
06:17:09 [ato]
ato: Yes.
06:17:25 [ato]
rniwa: Does the script WebDriver injects run in the same RIL as the page does?
06:18:03 [ato]
jgraham: If you can pass back a reference to an element inside the shadow DOM, then you can interact with it.
06:18:12 [ato]
... Because it all lives in the same JS realm.
06:19:11 [ato]
rniwa: WebKit has the ability to expose closed shadow DOMs are open.
06:21:04 [ato]
... We have the ability to make the closure route open [under certain circumstances].
06:22:34 [ato]
jgraham: The most straight approach would be for Find Element to return the shadow DOM root element if the found element is a shadow host element.
06:22:55 [ato]
diervo: That sounds like what we have done.
06:23:16 [ato]
jgraham: Potentially we have agreed here.
06:24:11 [ato]
s/straight approach/straight forward approach/
06:24:30 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html ato
06:24:34 [jgraham]
resolution: create a "Get Element Shadow" endpoint that takes the handle for an element and returns a handle for the associated shadow root, if any, or null if not
06:24:38 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html ato
06:25:59 [ato]
We will figure out the details later, but the intention is for the above to work on closed roots.
06:26:14 [jgraham]
s/shadow root/content-defined shadow root/
06:26:37 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html ato
06:26:58 [pmdartus]
pmdartus has joined #webdriver
06:26:59 [Hexcles]
Hexcles has joined #webdriver
06:28:46 [rakuco]
rakuco has joined #webdriver
06:38:33 [zcorpan]
zcorpan has joined #webdriver
06:40:28 [zcorpan]
zcorpan has joined #webdriver
06:43:47 [diervo]
diervo has joined #webdriver
06:45:12 [diervo_]
diervo_ has joined #webdriver
06:46:12 [zcorpan]
zcorpan has joined #webdriver
06:46:14 [pmdartus]
pmdartus has joined #webdriver
06:46:46 [zcorpan]
zcorpan has joined #webdriver
06:54:29 [diervo]
diervo has joined #webdriver
06:58:10 [zcorpan]
zcorpan has joined #webdriver
06:58:13 [zcorpan]
zcorpan has joined #webdriver
07:00:04 [Hexcles]
Hexcles has joined #webdriver
07:00:34 [diemol]
diemol has joined #webdriver
07:00:46 [titusfortner]
titusfortner has joined #webdriver
07:01:09 [diervo_]
diervo_ has joined #webdriver
07:02:35 [jihye]
jihye has joined #webdriver
07:02:49 [bwalderman]
bwalderman has joined #webdriver
07:02:49 [zcorpan]
zcorpan has joined #webdriver
07:03:09 [AutomatedTester]
https://mit.webex.com/mit/j.php?MTID=mf0c6a95eedfa61b9e4d6dbdc08e3798a
07:03:40 [spectranaut]
spectranaut has joined #webdriver
07:03:48 [spectranaut]
present +
07:04:07 [spectranaut]
present+
07:04:20 [JohnJansen]
present+
07:04:30 [spectranaut]
https://bocoup.github.io/presentation-aria-and-webdriver/#/
07:04:33 [zcorpan]
present+
07:04:37 [drousso]
drousso has joined #webdriver
07:06:45 [boaz]
boaz has joined #webdriver
07:06:48 [boaz]
present+
07:07:12 [ato]
Topic: ARIA & WebDriver
07:07:21 [ato]
https://bocoup.github.io/presentation-aria-and-webdriver/#/
07:07:30 [titusfortner]
present+
07:07:32 [ato]
zcorpan: Hi, I’m Simon.
07:07:49 [ato]
zcorpan: Promoting accessibility with incentivisng web authors with tools.
07:08:06 [ato]
... The idea behind this comes from jugglinmike.
07:08:25 [ato]
... ARIA and WebDriver are similar because they both aim enable [?] machines.
07:08:34 [ato]
... With WebDriver you have a script that interacts with the webpage.
07:08:55 [ato]
... When you use WebDriver you typically work with HTML directly, you get an element by their class name or ID or name.
07:09:11 [ato]
... Whereas with a screen reader they work with an accessibility tree which is influenced by ARIA information from the DOM.
07:09:41 [ato]
... There is an opportunity to have the same code path for both assisted technology interaction as for WebDriver.
07:10:00 [nao_watanabe_access]
nao_watanabe_access has joined #webdriver
07:10:00 [ato]
... There’s also an idea about assuming semantics that are required or recommended in the ARIA practices guidelines to simplify testing.
07:10:05 [ato]
... Specifically testing accessible applications.
07:10:17 [ato]
... ARIA Practices Guidelines is a document that non-normatively recommends how to use ARIA.
07:10:26 [ato]
... Design patterns and such.
07:10:33 [ato]
... "How to make a modal dialogue?"
07:10:37 [ato]
... "How to do a button?"
07:10:41 [diervo]
diervo has joined #webdriver
07:10:53 [ato]
... For example it recommends specific keyboard interactions.
07:11:04 [ato]
... Tab key should move focus, Escape should close the dialogue.
07:11:16 [ato]
... The developer has to implement this with JS to be follow these guidelines.
07:11:44 [jcraig]
jcraig has joined #webdriver
07:12:00 [ato]
spectranaut: Less test code, improved test stability, …?
07:12:22 [ato]
... [role="radio"] is ARIA defined role.
07:12:58 [ato]
... accessibleName() does a difficult thing.
07:13:49 [ato]
... Instead of these complicated code patterns, we’d like to see this built into WebDriver.
07:14:04 [ato]
... webdriver.setRadio("Thin crust")
07:14:46 [ato]
... Improved test stability: finding element’s that have ARIA popups could cause synchronisation issues with elements not being found.
07:15:24 [ato]
... We’d like to encapsulate these ARIA checks/patterns with a command.
07:15:33 [ato]
... For example webdriver.OpenPopup().
07:16:03 [ato]
... This would ensure for sure that the popups are there by running the checks internally.
07:16:18 [ato]
... Improved test resiliency: tests become brittle when they rely only on CSS selectors.
07:16:39 [ato]
... Page objects is one mitigation, but this is just another way ot mitigating brittle test writing by relying on the accessibility API.
07:16:56 [ato]
... Testing against the accessibility tree gives more stable tests over time.
07:17:32 [ato]
... Accessibility verified: we can add to these commands accessibility verification.
07:17:47 [ato]
... People don’t have to know ARIA to get the benefit of these.
07:18:21 [ato]
... For example, on a toggle button the text on the button shouldn’t change when it becomes depressed.
07:18:39 [ato]
... We could built this check into the WebDriver extension and have WebDriver return an error when the ARIA verification check fails.
07:18:55 [ato]
zcorpan: jugglinmike has done an implementation of this, with API documentation you can read.
07:19:11 [ato]
... I want to quickly step through the specification that jugglinmike wrote.
07:19:36 [zcorpan]
https://bocoup.github.io/aria-practices/aria-practices.html#automation-pushbutton
07:20:16 [ato]
... This is a new WebDriver command that gets the role of the element and computes it as is specified by the relevant specs.
07:20:37 [ato]
... Could be another extension to WebDriver to get the precomputed role from the browser, but this is not part of this specification.
07:20:52 [ato]
... If the role is not a button, it will fail. This is a type check.
07:21:20 [ato]
... It then gets the accessible name of the element and we return an error if the string is empty because all buttons in ARIA must have strings.
07:21:28 [ato]
s/have strings/non-empty strings/
07:21:40 [ato]
... If it’s a toggle button, it verifies that the state changed after pressing it.
07:21:51 [ato]
... It then tries to ‘use’ the button.
07:22:03 [ato]
... This is a new term that depends on the interaction mode that the tester has.
07:22:07 [ato]
... Mouse, keyboard, touch mode.
07:22:17 [ato]
... Different code paths when you use the button.
07:23:12 [ato]
... It then compare the old state value with the new one.
07:23:52 [ato]
... The accessible name should not change as the result of using a button, and it returns an error if it has.
07:23:59 [ato]
... Then if everything went fine, we’re done.
07:24:10 [ato]
spectranaut: Some points of discussion we have are listed.
07:24:57 [ato]
... The stale element reference could happen inside the algorithm to use the button, and we don’t know how to solve this,.
07:25:26 [ato]
... We have some concerns about the ARIA recommendation spec stability.
07:25:30 [zghadyali]
zghadyali has joined #webdriver
07:25:45 [ato]
... Is this something that belongs in WebDriver?
07:26:00 [AutomatedTester]
q?
07:26:01 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html ato
07:26:41 [ato]
simonstewart: Is there a normative spec?
07:26:45 [ato]
spectranaut: Not exactly
07:26:59 [ato]
... They are non-normative suggestions for how to make an accessible website.
07:27:21 [ato]
q?
07:28:00 [ato]
AutomatedTester: This should not live in the WebDriver specification, because it is more about low-level tasks.
07:28:11 [ato]
... Here many things can happen along the way.
07:28:24 [ato]
zcorpan: I agree APG stuff should probably not be in the core WebDriver spec.
07:28:24 [ato]
q+
07:28:40 [ato]
... The exposing of the accessible name and the exposure of the computed role is something could be in the core WebDriver spec.
07:28:48 [AutomatedTester]
q?
07:29:01 [ato]
... Computation of the accessible name etc. is normatively specified.
07:29:10 [titusfortner]
q+
07:29:22 [ato]
simonstewart: If there's a normative source for it, that would be the logical place to put the WebDriver extension for it.
07:29:58 [jcraig]
Q+
07:30:30 [MikeSmith]
q?
07:30:34 [AutomatedTester]
ack ato
07:30:49 [AutomatedTester]
scribenick: automatedtester
07:31:36 [AutomatedTester]
ato: there is a similar impl. in Firefox webdriver. You can set a capability and then get a bunch of a11y checks using the a11y tree
07:32:20 [simonstewart]
simonstewart has joined #webdriver
07:32:29 [AutomatedTester]
q?
07:32:32 [jcraig]
Q+ to mention label should not be tied to the accname spec. These are primitives that differ per implementation.
07:33:03 [ato]
ScibreNick: ato
07:33:04 [AutomatedTester]
ack titusfortner
07:33:05 [ato]
ScribeNick: ato
07:33:14 [ato]
ato: I think this is a good idea.
07:33:26 [ato]
titusfortner: What is ARIA? Where are the roles stored?
07:33:29 [CalebRouleau]
CalebRouleau has joined #webdriver
07:33:44 [ato]
... In Watir we’ve done some work to make it possible to retrieve ARIA elements.
07:33:49 [ato]
... Or by ARIA selectors.
07:34:32 [ato]
zcorpan: Accessible Name and Description Computation 1.2 looks at some of the attributes, but also looks at some of the existing attributes of elements, for example <img alt="whatever">.
07:35:03 [AutomatedTester]
q?
07:35:21 [ato]
ato: These are heuristics for assisted technology, right?
07:35:36 [ato]
zcorpan: Yes, except the ARIA roles are normatively defined.
07:35:47 [ato]
jcraig: ARIA practices guide is non-normative best practices.
07:36:15 [ato]
... The ARIA spec is normative and defines roles, maps to accessibility technologies on the platform.
07:36:42 [ato]
... Accessible names spec is normative and exposes the heuristics of finding the right elements according to roles.
07:36:49 [AutomatedTester]
ack jcraig
07:36:49 [Zakim]
jcraig, you wanted to mention label should not be tied to the accname spec. These are primitives that differ per implementation.
07:36:49 [jcraig]
Ack me
07:37:28 [AutomatedTester]
q+
07:37:54 [ato]
... The accessibility roles are implemented by the web browsers, and through adding this to WebDriver we could also check the browsers against themselves.
07:38:41 [ato]
ato: Is ARIA tested in WPT?
07:39:12 [MikeSmith]
https://github.com/web-platform-tests/wpt/tree/master/wai-aria
07:39:21 [ato]
jcraig: Not currently to my knowledge, because it doesn’t have hooks for each browser’s accessibility engine.
07:39:37 [boaz]
titusfortner: can you link to water?
07:39:44 [titusfortner]
http://watir.com
07:40:12 [ato]
jcraig: [something about hooking into the system level accessibility API]
07:40:21 [titusfortner]
specifically: http://watir.com/guides/locating/#aria-attributes
07:40:44 [ato]
simonstewart: If you set the preferred input device in WebDriver, it would be great if the high-level APIs in WebDriver would use that.
07:41:28 [simonstewart]
simonstewart has joined #webdriver
07:41:33 [ato]
... WebDriver Element Click signals an intent that, say, a button would prefer this input method.
07:41:39 [simonstewart]
present+
07:41:42 [ato]
AutomatedTester: It would need to be opt-in, through a flag or capability.
07:41:47 [ato]
... The default should be off.
07:41:55 [ato]
zcorpan: I understand the concern that we don’t want to break existing tests.
07:42:12 [ato]
q+
07:42:17 [ato]
ack AutomatedTester
07:42:25 [simonstewart]
q?
07:42:31 [AutomatedTester]
ack ato
07:43:13 [cb]
ato: in geckodriver the user has to opt in
07:44:07 [ato]
ato: It seems the question should be if the ARIA checks should be tied to Element Click/Element Send Keys, or if they should be separate ARIA-specific commands.
07:44:23 [ato]
ato: simonstewart wanted the formed, and this is how it currently works with the accessibility checks in geckodriver.
07:44:30 [ato]
ato: But I’m on the fence.
07:45:04 [jcraig]
s/[something about hooking into the system level accessibility API]/best ideas from the preso are the primitives: label & role #1439 and the “getter by label” #1441/
07:45:07 [ato]
[Technical discussion about how the extension should be done.]
07:45:24 [ato]
simonstewart: I would like this to live in ARIA, but I’m not sure if WebDriver should explicitly call that.
07:45:41 [ato]
AutomatedTester: What would be the performance hit of having the accessibility tree turned on?
07:45:52 [ato]
jcraig: It’s non-zero. Sometimes significant.
07:45:58 [ato]
zcorpan: Users pay if they use a screen reader.
07:46:06 [ato]
... It seems a reasonable cost if you’re testing accessibility.
07:47:24 [JohnJansen]
q?
07:48:23 [jcraig]
Q+ to discuss the more complex issues with APG-based testing
07:48:42 [ato]
AutomatedTester: We could use Firefox as an example here and document what it does.
07:49:05 [JohnJansen]
q+
07:49:20 [jgraham]
ack JohnJansen
07:49:38 [ato]
JohnJansen: How is the Firefox implementation different from the PR that is presented?
07:52:15 [ato]
[Some discussion about how Firefox works.]
07:52:45 [ato]
ato: I don’t think we should base this off the Firefox implementation. I was just saying that there is presedence for building accessibility checks into WebDriver primitives.
07:52:47 [jgraham]
ack
07:52:50 [jcraig]
Ack me
07:52:50 [Zakim]
jcraig, you wanted to discuss the more complex issues with APG-based testing
07:52:51 [zcorpan]
q?
07:53:48 [ato]
jcraig: ARIA can affect what the label is, as can the label attribute in HTML, but it’s not specifically tied to ARIA.
07:54:00 [AutomatedTester]
https://github.com/w3c/webdriver/issues/1439
07:54:11 [ato]
... There may be some way to write a library that can have some assumption about what roles are activated.
07:54:32 [ato]
... But you quickly get in to complicated trees.
07:55:32 [ato]
jgraham: Some of the other stuff we’re discussing today is fundamental architecture work that is quite important to people.
07:55:44 [ato]
... In terms of resourcing I’m not sure if this is going to be our top priority.
07:57:18 [boaz]
and https://github.com/w3c/webdriver/issues/1439
07:57:27 [boaz]
sorry, and https://github.com/w3c/webdriver/issues/1441
07:57:36 [ato]
brrian: I’m curious about the performance penalty?
07:57:59 [ato]
jcraig: It should probably be opt-in as there is some initial cost to spinning up the accessibility tree.
07:58:24 [ato]
... I don’t think the implementation is much, but there will be performance cost at runtime. For this reason it should be opt-in.
07:59:27 [ato]
jgraham: Does anybody feel like they’re writing the spec text for this?
07:59:35 [ato]
jcraig: I can commit to advising.
07:59:44 [ato]
AutomatedTester: I don’t think it’s going to be that much.
07:59:56 [ato]
... So I can commit to working with jcraig.
08:00:02 [ato]
JohnJansen: I’m not against it at all.
08:00:32 [ato]
AutomatedTester: I’m happy to get a PR and tests up.
08:00:53 [ato]
jcraig: Are people optimistic about the second issue I filed?
08:00:58 [ato]
jcraig: Get element by its label?
08:02:16 [ato]
jgraham: I have a DOM tree, how do I tell what the accessible name is? Do I have to turn on the accessible tree?
08:02:51 [ato]
jcraig: I believe each implementation has a reverse implementation from accessibility node back to the element.
08:03:10 [ato]
jgraham: Is there a DOM API that is "get accessible name for node"?
08:04:01 [ato]
jcraig: For example, if a cell is not contained inside a row then we don’t expose it as a valid cell.
08:04:17 [ato]
zcorpan: On the question, is the information in the DOM enough?
08:04:19 [ato]
... The answer is no.
08:04:34 [ato]
... It includes CSS generated content and shadow DOM.
08:04:48 [ato]
... You want the flat tree + CSS generated content.
08:04:55 [ato]
... This makes out the accessibility tree.
08:05:06 [ato]
... The accessibility tree is the same as the render tree, but for spoken output.
08:05:18 [ato]
... The render tree is for the visual output.
08:06:37 [ato]
[Discussion about how ARIA works.]
08:09:02 [ato]
q?
08:11:17 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html ato
08:12:51 [ato]
Topic: Get Element Text
08:14:03 [ato]
simonstewart: We use an atom because there was at the time no interoperable implementation of getInnerText().
08:14:17 [ato]
... We agreed in the past that we should move to use the platform API when all the browsers supported it.
08:14:20 [ato]
... And now they do.
08:14:34 [ato]
jgraham: There was agreement in the past that we should do this, but behind a capability.
08:14:53 [ato]
... Now is the time to do it.
08:15:45 [ato]
RESOLUTION: We should add capability to opt in to the platform getInnerText() for Get Element Text
08:16:47 [ato]
Topic: Maximum timeout to set over 1 minute
08:19:59 [ato]
Topic: Text input spec modification
08:20:10 [JohnJansen]
https://github.com/w3c/webdriver/issues/1430
08:20:23 [ato]
JohnJansen: It’s a bug.
08:20:47 [ato]
JohnJansen: We missed the case that you’ve already selected an element. The spec says you should always start at the end of the text.
08:20:55 [KaL]
KaL has joined #webdriver
08:21:34 [ato]
simonstewart: Send Keys always resets the caret to the end of the text field.
08:21:58 [ato]
JohnJansen: Firefox implements this the way I expect, but which is in violation of the spec.
08:22:05 [ato]
... I think everyone agreed this was an oversight.
08:25:11 [ato]
RESOLUTION: The caret in Element Send Keys should move on calling the command again
08:25:34 [ato]
Topic: Adding the step to handle user prompts for screenshots
08:28:09 [simonstewart]
Scribe: sstewart
08:28:16 [simonstewart]
scribe: simonstewart
08:28:19 [ato]
ScribeNick: simonstewart
08:28:19 [AutomatedTester]
scribenick: simonstewart
08:28:42 [simonstewart]
ato: do the js dialog prompts stop you from taking the screenshots?
08:28:49 [simonstewart]
ato: why do we want them to go away?
08:29:11 [simonstewart]
jgraham: implementations may not be able to take a screenshot if an alert is displayed
08:29:36 [simonstewart]
ACTION: AutomatedTester to approve PR
08:30:11 [simonstewart]
CalebRouleau: wonders if alerts should block js at all
08:30:18 [simonstewart]
nerdery about specs follows
08:30:39 [simonstewart]
Topic: Clarify handling of unrecognised extension capabilities
08:31:36 [simonstewart]
JohnChen: should we accept or reject unrecognised extension capabilities
08:32:31 [simonstewart]
jgraham: two cases. All capabilities have a prefix. geckodriver might understand "moz:" but there might be something that means "moz:foo" isn't recognised
08:32:54 [simonstewart]
ato: capabilities used to pass in config to end point nodes. Also to provide additional configuration to intermediary nodes
08:33:16 [simonstewart]
ato: should intermediary nodes prune capabilities?
08:34:01 [simonstewart]
simonstewart: I had a spec change ready to allow intermediary nodes to delete capabilities as needed
08:34:20 [simonstewart]
JohnChen: there's one WPT test that expects the unrecognised capability should be rejected
08:34:51 [simonstewart]
ato: looks up the test and all browsers fail it
08:35:09 [ato]
https://wpt.fyi/results/webdriver/tests/new_session/default_values.py?label=experimental&label=master&aligned
08:35:26 [simonstewart]
jgraham: explains how geckodriver works, and claims this is the desired spec behaviour
08:36:08 [simonstewart]
jgraham: browser ignores capabilities that start with a prefix that's not specific to the browser, it's ignored. If there's a capability with a (eg) "moz:" prefix that's not recognised, the session fails
08:36:31 [simonstewart]
jgraham: the spec is currently in a degenerate state
08:37:35 [simonstewart]
jgraham: if any capability with that prefix is accepted by the driver, but the capability is unknown to the driver, an error should be thrown. Otherwise the extension capability should be accepted
08:37:53 [karl]
karl has joined #webdriver
08:38:12 [simonstewart]
ato: does this mean we need to look at all capabilities
08:38:21 [simonstewart]
jgraham: yes. You can't just pull out "known things"
08:38:39 [simonstewart]
ato: normally we ignore additional data in payloads
08:38:46 [simonstewart]
jgraham: explicitly not with capabilities
08:39:06 [simonstewart]
jgraham: suggests what he's suggested before as a change to the spec
08:39:37 [simonstewart]
ato: is that needed?
08:40:20 [simonstewart]
jgraham: the reason for this proposed handling is that if someone passes in something with a typo, they fail fast.
08:40:27 [simonstewart]
lukebjerring: but they could typo the prefix
08:40:44 [simonstewart]
jgraham: but this makes it easier to handle capabilities uniformly
08:41:37 [simonstewart]
JohnChen: for chrome there are some extensions that use "goog:" but aren't actually chrome extensions --- they're ones from other parts of google
08:42:14 [simonstewart]
JohnChen: Maybe we should have used the "chrome" prefix
08:43:09 [simonstewart]
jgraham: if the point is that chromedriver is never throwing an error, then this change would be a breaking change for them
08:43:21 [simonstewart]
ato: I ran into a bug the other week
08:43:54 [simonstewart]
ato: to do with chromedriver extension capabilities. We stored the data in geckodriver, and it was waaay too large
08:44:23 [simonstewart]
ato: selenium clients send massive blobs all the time, since they do double locations (the protocol handshake with the old protocol)
08:44:40 [simonstewart]
lukebjerring: I'd argue there's not a clear benefit
08:45:22 [simonstewart]
jgraham: the other reason is to do with the matching. The spec spelled out what was allowed.
08:46:23 [diervo]
diervo has joined #webdriver
08:49:13 [simonstewart]
simonstewart: explains original behaviour and reasoning behind it
08:49:57 [simonstewart]
simonstewart: suggests end nodes abandon session creation on any unrecognised capability, and intermediary nodes to strip capabilities that are specific to the intermediary
08:50:18 [simonstewart]
jgraham: wonders aloud whether end nodes are getting capabilities that they don't recognise
08:50:50 [simonstewart]
JohnChen: we might get some resistance from the internal test team
08:51:48 [simonstewart]
CalebRouleau: "extension capabilities are a free for all, and we should accept that"
08:52:02 [simonstewart]
lukebjerring: is there a need to reject unrecognised extension capabilities
08:52:23 [simonstewart]
jgraham: yes. eg. different browser versions that support different capability names
08:53:08 [simonstewart]
ato: it seems like what we're agreeing to is to accept jgraham's proposal?
08:53:28 [simonstewart]
jgraham: no. If there's a colon in the name and you don't recognise the name, we accept that capability
08:54:27 [simonstewart]
jgraham: compares chrome's lax approach with gecko's stricter approach
08:54:40 [simonstewart]
CalebRouleau: attempts to use the word SHOULD
08:54:50 [simonstewart]
ato: it MUST NOT have the word SHOULD
08:55:52 [simonstewart]
lukebjerring: the existing test doesn't highlight the difference in behaviour between chrome and firefox
08:56:56 [simonstewart]
simonstewart: we could just grab the "example" extension capability for ourselves
09:00:38 [simonstewart]
simonstewart: so we're back to the original desired capabilities pattern?
09:00:45 [simonstewart]
jgraham: yes
09:01:46 [jgraham]
resolution: For extension capabilites that are unknown to the implementation the result of validating capabilities must always be to accept the capability i.e. unknown extension capabilities never cause matching to fail irrespective of whether the extension prefix is known to the implementation
09:02:54 [jgraham]
action: (someone) to update the tests to include moz:foo goog:foo etc. and ensure that matching doesn't fail
09:03:05 [Hexcles]
Hexcles has joined #webdriver
09:03:15 [jgraham]
RRSAgent: make minutes
09:03:15 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/19-webdriver-minutes.html jgraham
09:03:19 [jgraham]
RRSAgent: done
09:03:19 [RRSAgent]
I'm logging. I don't understand 'done', jgraham. Try /msg RRSAgent help
09:03:27 [jgraham]
RRSAgent: stop logging
09:03:27 [RRSAgent]
I'm logging. I don't understand 'stop logging', jgraham. Try /msg RRSAgent help
09:03:30 [simonstewart]
simonstewart has joined #webdriver
09:03:51 [jgraham]
RRSAgent: stop