Meeting minutes
<jgraham> RRSAgent: make logs public
<jgraham> RRSAgent: make minutes
TPAC
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
various: most people describe whether they're planning on going
whimboo: is registration open, and what about the timezone?
jgraham: Yes, registration is open. Remote participants need to pay to attend too.
jgraham: Browser Testing and Tools is for Thursday and Friday (15-16 September)
whimboo: will the meeting also happen on IRC?
jgraham: Yes, it will, as usual
Network request logging
<jgraham> github: https://
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
jgraham: last time, the two main questions were about redirects, and what to do with chunked responses. Research has been done!
jgraham: Chunked responses are not supported in any meaningful way anywhere. In particular, trailing headers are inaccessible in CDP and Firefox devtools
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
jgraham: Similarly, the request for a redirect only gets the extra-info event.
jgraham: option 1 is to do what CDP does here. When we think about this, there are a few use cases.
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
jgraham: if we copy the CDP model, case 2 would register for everything, and case 1 for only one event
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
jgraham: so if you use case 2, you'd register for both events.
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.
patrickangle: people want to know that a network event has occurred, and having a single set of events makes this clearer.
jgraham: I'm not sure. My concern with a single set of events is whether we want to support use-case 1.
<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.
jgraham: sounds like people want one event with a flag on it, rather than multiple different events.
jgraham: would be interesting to know how CDP ended up with two events....
jgraham: if anyone knows, please update the PR
Associate known elements with a window rather than browsing context
<jgraham> github: https://
jgraham: this applies to both webdriver classic and bidi
<jgraham> https://
jgraham: original question was whether we had a per-window or per-browsing context list of elements
jgraham: conclusion was that it was probably okay to have a per-window list, which is easier to implement
jgraham: result would be that stale element exceptions are no longer returned
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)
jgraham: unfortunately, the answer to this is that none of this should work, because the elements were found from different browsing contexts
jgraham: probably not what users expect or implementations do
jgraham: firefox always gives the same element ID. chromedriver sometimes gives the same element ID.
whimboo: if we have this per-window, it would be consistent whether the frames were in the same process or not.
<jgraham> https://
<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.
sadym: I remember using Selenium and always having problems with stale element exceptions
sadym: so we just used to get elements every time we wanted to use them
<jgraham> simonstewart: That seems a bit more like a selenium-specific problem.
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
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.
<jgraham> simonstewart: We could loosen the classic spec to not require a UUID, if that helps.
<jgraham> simonstewart: UUIDs are a should-level requirement
various: discussion about internals of CDP
whimboo: for firefox, we have a js module that generates unique ids for elements. These are floating numbers
What's Julian's IRC nick?
<jdescottes> jdescottes
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"?
jgraham: At the moment, "yes".
Add propert(y|ies) to determine if Element is stale on serialization
<jgraham> github: https://
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
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?
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
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
<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.
sadym: I still have a question about whether we need the stale element exception.
<jgraham> simonstewart: People use it as a mechanim for figuring out whether the page redrew without a reload for example.
<jgraham> sadym: How would it work with react?
<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.
sadym: we want to provide a way for bidi users to tell if the node is in the active dom or not?
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
jgraham: the common use case is where something has been removed from the DOM, but a reference is still held in JS
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
<jgraham> github: https://
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
diemol: in Selenium Grid, people connect Appium to the Grid, and the intermediary node explode
diemol: The proposal is for validation of locator strategies to be done at the end point
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
jgraham: one fix may be for there to be "extension locator strategies"
<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.
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
jgraham: Appium could register some known locator strategy names. That might solve the problem that they have now
diemol: So should Appium should register their extensions somewhere?
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
diemol: not sure how efficient that will be. Doesn't solve the problem of third party vendors wanting their own locator strategies
diemol: do we care whether we need to do this in the intermediary nodes?
<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.
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
jgraham: EOM
<jgraham> RRSAgent: make minutes