15:52:10 <RRSAgent> RRSAgent has joined #webdriver
15:52:10 <RRSAgent> logging to https://www.w3.org/2022/07/13-webdriver-irc
15:52:15 <Zakim> Zakim has joined #webdriver
15:53:03 <jgraham> Meeting: WebDriver-BiDi
15:53:21 <jgraham> Agenda: https://www.w3.org/wiki/index.php?title=WebDriver/2022-07-BiDi&action=edit&section=2
15:53:30 <jgraham> RRSAgent: make logs public
15:53:36 <jgraham> RRSAgent: make minutes
15:53:36 <RRSAgent> I have made the request to generate https://www.w3.org/2022/07/13-webdriver-minutes.html jgraham
15:56:36 <brwalder> brwalder has joined #webdriver
15:56:57 <patrickangle> patrickangle has joined #webdriver
16:01:59 <jdescottes> jdescottes has joined #webdriver
16:01:59 <jgraham> present+
16:02:07 <brwalder> present+
16:02:07 <whimboo> present+
16:02:12 <jdescottes> present+
16:02:14 <diemol> present+
16:02:17 <patrickangle> present+
16:03:09 <Sasha> present+
16:04:12 <simonstewart> simonstewart has joined #webdriver
16:04:37 <jgraham> Agenda: https://www.w3.org/wiki/index.php?title=WebDriver/2022-07-BiDi#Agenda
16:05:03 <sadym> present+
16:05:17 <simonstewart> present+
16:05:47 <jgraham> ScribeNick: simonstewart
16:05:53 <jgraham> Chair: jgraham
16:06:02 <jgraham> topic: TPAC
16:07:06 <simonstewart> jgraham: registration is now open if people want to go. Also need remote participants to register. Would be interesting to know who is planning to be there
16:08:22 <simonstewart> various: most people describe whether they're planning on going
16:08:57 <simonstewart> whimboo: is registration open, and what about the timezone?
16:09:18 <simonstewart> jgraham: Yes, registration is open. Remote participants need to pay to attend too.
16:09:34 <simonstewart> jgraham: Browser Testing and Tools is for Thursday and Friday (15-16 September)
16:10:09 <simonstewart> whimboo: will the meeting also happen on IRC?
16:10:15 <simonstewart> jgraham: Yes, it will, as usual
16:10:31 <jgraham> topic: Network request logging
16:10:39 <jgraham> github: https://github.com/w3c/webdriver-bidi/pull/204
16:11:51 <simonstewart> jgraham: updates on the previous discussion: draft PR up with a rough sketch of the API for logging network events. Is a prelude for network interception
16:12:15 <simonstewart> jgraham: last time, the two main questions were about redirects, and what to do with chunked responses. Research has been done!
16:12:46 <simonstewart> jgraham: Chunked responses are not supported in any meaningful way anywhere. In particular, trailing headers are inaccessible in CDP and Firefox devtools
16:13:32 <simonstewart> jgraham: Redirects do need to be supported. CDP has two separate events which it sends for normal requests and responses containing extra info. If you get a redirect, you only get the extra info event
16:13:55 <simonstewart> jgraham: Similarly, the request for a redirect only gets the extra-info event.
16:14:32 <simonstewart> jgraham: option 1 is to do what CDP does here. When we think about this, there are a few use cases.
16:15:02 <simonstewart> jgraham: 1/ People who don't care about redirects, and just want to read the response body. 2/ when you do care about redirects because you want to debug network connections
16:15:26 <simonstewart> jgraham: if we copy the CDP model, case 2 would register for everything, and case 1 for only one event
16:16:22 <simonstewart> jgraham: Two options in the PR. 1/ if it's a redirect, there's a flag in the body. 2/ we have two completely separate sets of events: one for a user initiated request, and another for response/request pairs which are part of a redirect
16:16:43 <simonstewart> jgraham: so if you use case 2, you'd register for both events.
16:16:49 <jgraham> q?
16:17:08 <patrickangle> q+
16:17:17 <jgraham> ack patrickangle
16:17:37 <simonstewart> patrickangle: looking at the PR, it seems like it would be better for clients and people using the APIs if all network events were treated the same way.
16:18:06 <simonstewart> patrickangle: people want to know that a network event has occurred, and having a single set of events makes this clearer.
16:18:46 <simonstewart> jgraham: I'm not sure. My concern with a single set of events is whether we want to support use-case 1.
16:18:54 <simonstewart> q+
16:19:11 <jgraham> ack simonstewart
16:19:52 <jgraham> simonstewart: For a user having fewer events to subscribe to makes a simpler model. In our experience people are interested in redirects, even if they don't really want to log that.
16:20:00 <jgraham> q?
16:20:26 <simonstewart> jgraham: sounds like people want one event with a flag on it, rather than multiple different events.
16:20:39 <simonstewart> jgraham: would be interesting to know how CDP ended up with two events....
16:21:03 <jgraham> q?
16:21:04 <simonstewart> jgraham: if anyone knows, please update the PR
16:21:29 <jgraham> topic: Associate known elements with a window rather than browsing context
16:21:39 <jgraham> github: https://github.com/w3c/webdriver/pull/1667
16:22:12 <simonstewart> jgraham: this applies to both webdriver classic and bidi
16:22:26 <jgraham> https://github.com/w3c/webdriver/issues/1594
16:22:33 <simonstewart> jgraham: original question was whether we had a per-window or per-browsing context list of elements
16:22:57 <simonstewart> jgraham: conclusion was that it was probably okay to have a per-window list, which is easier to implement
16:23:24 <simonstewart> jgraham: result would be that stale element exceptions are no longer returned
16:24:14 <simonstewart> jgraham: there is a bigger question here: what happens if you shuffle elements between windows (eg. return an iframe's parent's body from two different iframes with the same parent)
16:25:03 <simonstewart> jgraham: unfortunately, the answer to this is that none of this should work, because the elements were found from different browsing contexts
16:25:29 <simonstewart> jgraham: probably not what users expect or implementations do
16:25:52 <simonstewart> jgraham: firefox always gives the same element ID. chromedriver sometimes gives the same element ID.
16:26:38 <jgraham> q?
16:26:43 <whimboo> q+
16:26:50 <jgraham> ack whimboo
16:26:51 <simonstewart> q+
16:26:57 <sadym> q+
16:27:16 <simonstewart> whimboo: if we have this per-window, it would be consistent whether the frames were in the same process or not.
16:27:42 <jgraham> https://github.com/web-platform-tests/wpt/pull/34834 is a draft PR with some relevant tests.
16:27:45 <jgraham> ack simonstewart
16:29:09 <jgraham> simonstewart: The question is what are people going to do with the element ids once they've got them? In Selenium, people just do a find element or similar. They don't compare element ids directly. We don't have issues reported on this. I'm not sure that use case is important. From a practical point of view this might not matter much.
16:29:19 <jgraham> ack sadym
16:29:40 <simonstewart> sadym: I remember using Selenium and always having problems with stale element exceptions
16:30:01 <simonstewart> sadym: so we just used to get elements every time we wanted to use them
16:30:13 <jgraham> q+
16:30:37 <jgraham> simonstewart: That seems a bit more like a selenium-specific problem.
16:30:42 <jgraham> ack jgraham
16:31:37 <sadym> q+
16:32:04 <simonstewart> jgraham: I think having a list per-window and having a different ID for the same thing from different windows is mostly okay. Would be weird if the same shared ID (between classic and bidi) is returned based on which context you access the element through
16:32:24 <jgraham> ack sadym
16:33:25 <simonstewart> sadym: talking about sharing ids between bidi and classic. There's a limitation in the CDP, because in classic it must be a GUID, but in CDP we can't do that.
16:33:30 <simonstewart> q+
16:33:34 <jgraham> ack simonstewart
16:34:08 <jgraham> simonstewart: We could loosen the classic spec to not require a UUID, if that helps.
16:35:33 <whimboo> q+
16:35:37 <simonstewart_> simonstewart_ has joined #webdriver
16:36:19 <jgraham> simonstewart: UUIDs are a should-level requirement
16:36:23 <simonstewart> various: discussion about internals of CDP
16:36:25 <jgraham> ack whimboo
16:36:53 <simonstewart> whimboo: for firefox, we have a js module that generates unique ids for elements. These are floating numbers
16:37:05 <jgraham> q?
16:37:06 <jdescottes> q+
16:37:11 <jgraham> ack jdescottes
16:37:58 <simonstewart> What's Julian's IRC nick?
16:38:44 <jdescottes> jdescottes
16:39:48 <simonstewart> jdescottes: if we have two windows connected to each other (win1, win2), and you're retreieving an element from win2 via win1, and win1 navigates away. Win1 will have lost the element reference. What should we do in that case? Throw a "no such element"?
16:40:28 <simonstewart> jgraham: At the moment, "yes".
16:40:59 <jgraham> q?
16:41:24 <jgraham> topic: Add propert(y|ies) to determine if Element is stale on serialization
16:41:31 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/236
16:42:32 <simonstewart> jgraham: in classic webdriver we have the concept of stale elements, which are elements that might or might not exist, but are disconnected from the tree that they were in, or that the page might have navigated
16:43:02 <simonstewart> jgraham: we want to be able to implement webdriver classic on a webdriver bidi backend. What properties do we want to put on the serialisation to indicate the element is stale?
16:44:05 <simonstewart> jgraham: if element cache is per-window and separate for each window, the only thing the staleness is checking is whether the element is connected or not to the underlying document. Use a "connected" property
16:44:54 <simonstewart> jgraham: if it's possible to get an element from a document that's no longer active, then things become trickier, and we have bidi have a property that assigns a value of what classic thinks staleness is
16:45:01 <simonstewart> q+
16:45:06 <jgraham> ack simonstewart
16:45:07 <sadym> q+
16:45:21 <sadym> q-
16:46:11 <jgraham> simonstewart: The reason for the staleness check is that early webdriver stored the list of elements in a js array on the window. If someone removed an element we'd still have a reference, so we had to check if we were the only reference to the element. Checking for connection might be good enough.
16:46:14 <sadym> q-
16:46:16 <sadym> q+
16:46:18 <jgraham> q?
16:46:39 <jgraham> ack sadym
16:47:04 <simonstewart> sadym: I still have a question about whether we need the stale element exception.
16:47:40 <jgraham> simonstewart: People use it as a mechanim for figuring out whether the page redrew without a reload for example.
16:47:52 <jgraham> sadym: How would it work with react?
16:48:28 <jgraham> simonstewart: If react rebuilds the whole DOM, you could get a stale element exception. With that model you often use the element as soon as getting it.
16:48:33 <jgraham> q?
16:48:59 <simonstewart> sadym: we want to provide a way for bidi users to tell if the node is in the active dom or not?
16:49:32 <simonstewart> jgraham: yes, that is a good use case. I came at it from the point of view of being able to implement classic on top of bidi. There are use cases for classic's behaviour
16:50:08 <simonstewart> jgraham: the common use case is where something has been removed from the DOM, but a reference is still held in JS
16:50:55 <simonstewart> jgraham: we could start by adding a property on nodes which say whether they're connected or not, and then the rest of this depends on where we land when considering element caches
16:51:53 <jgraham> jgraham has changed the topic to: Custom Locator Strategies validation
16:52:03 <jgraham> github: https://github.com/w3c/webdriver/pull/1671
16:52:36 <simonstewart> diemol: the context of this is that the classic spec has a set of locator strategies, and the remote end has to return an error if someone is using something different
16:53:01 <simonstewart> diemol: in Selenium Grid, people connect Appium to the Grid, and the intermediary node explode
16:53:27 <simonstewart> diemol: The proposal is for validation of locator strategies to be done at the end point
16:55:05 <simonstewart> jgraham: There are probably cases where what the spec says what you're meant to do is aimed at the end node, and not intermediary nodes
16:55:06 <simonstewart> q+
16:55:45 <simonstewart> jgraham: one fix may be for there to be "extension locator strategies"
16:56:10 <diemol> q+
16:56:13 <jgraham> ack simonstewart
16:57:27 <jgraham> simonstewart: Selenum Grid will just forward what it gets without checking, unless it's doing protocol conversions. That might apply to appium. We could exclude intermediary nodes from the locator strategy part.
16:57:33 <jgraham> ack diemol
16:58:49 <simonstewart> diemol: two things. First: prefixed locator strategies was the original idea, and the Appium team said that this would need to be a huge change for them. Second: Appium is currently using the w3c protocol, and that's why it ends up checking the locator strategy
17:00:16 <simonstewart> jgraham: Appium could register some known locator strategy names. That might solve the problem that they have now
17:00:51 <jgraham> q?
17:01:03 <diemol> q+
17:01:48 <simonstewart> diemol: So should Appium should register their extensions somewhere?
17:02:28 <simonstewart> jgraham: Kind of. There could be a PR for the W3C spec that talks about locator extensions, and a separate document where Appium lists them
17:03:46 <simonstewart> diemol: not sure how efficient that will be. Doesn't solve the problem of third party vendors wanting their own locator strategies
17:03:49 <simonstewart> q+
17:03:56 <jgraham> ack diemol
17:04:14 <simonstewart> diemol: do we care whether we need to do this in the intermediary nodes?
17:04:18 <jgraham> ack simonstewart
17:05:07 <jgraham> simonstewart: I'm pretty sure the spec is very loose about what an intermediary node should do. I think we should check that before moving forward with this PR. I think the spec allows different behaviour for intermediaries.
17:05:39 <simonstewart> jgraham: I will write up something on the issue about what I was thinking. Sounds like simonstewart will look up what the spec actually says
17:05:41 <simonstewart> jgraham: EOM
17:05:59 <jgraham> RRSAgent: make minutes
17:05:59 <RRSAgent> I have made the request to generate https://www.w3.org/2022/07/13-webdriver-minutes.html jgraham
17:06:04 <jgraham> Zakim: bye
17:07:08 <jgraham> github-bot, end topic
17:07:44 <jgraham> RRSAgent, bye
17:07:44 <RRSAgent> I see no action items