16:47:10 <RRSAgent> RRSAgent has joined #webdriver
16:47:10 <RRSAgent> logging to https://www.w3.org/2022/12/14-webdriver-irc
16:47:17 <Zakim> Zakim has joined #webdriver
16:49:26 <jgraham> Meeting: WebDriver
16:49:44 <jgraham> Agenda: https://www.w3.org/wiki/WebDriver/2022-12-BiDi#Agenda
16:51:02 <jgraham> RRSAgent: make logs public
16:51:05 <jgraham> RRSAgent: make minutes
16:51:05 <RRSAgent> I have made the request to generate https://www.w3.org/2022/12/14-webdriver-minutes.html jgraham
16:57:51 <patrickangle_> patrickangle_ has joined #webdriver
17:00:32 <brwalder> brwalder has joined #webdriver
17:02:50 <brwalder> present+
17:02:59 <jgraham> present+
17:03:03 <whimboo> present+
17:03:03 <jdescottes> present+
17:03:13 <Sasha> present+
17:03:22 <jgraham> Topic: WebDriver Build fixups
17:03:29 <sadym> present+
17:04:08 <sadym> q+
17:04:14 <jgraham> Scribe: jgraham
17:04:46 <jgraham> jgraham: Made a PR to fix the build for HTML changes. Doesn't fix the underlying problems, but enough to allow other work to go ahead.
17:04:52 <jgraham> ack sadym
17:05:04 <patrickangle_> present+
17:05:09 <jgraham> sadym: I'm happy to review this, but I'm not a formal approver for WebDriver
17:05:30 <cb> present+
17:05:39 <jgraham> Simon: I an approve
17:05:48 <jgraham> jgraham: We don't have codeowners any more
17:05:59 <jgraham> sadym: I don't have enough access to do reviews.
17:06:29 <jgraham> jgraham: We should give sadym permissions to do reviews
17:06:55 <jgraham> Topic: shared IDs
17:07:04 <jgraham> github: https://github.com/w3c/webdriver-bidi/pull/180
17:07:52 <jgraham> sadym: PR with Node cache on the WebDriver spec, so we don't have different caches for Element, ShadowRoot.
17:08:08 <jgraham> sadym: I haven't looked at this PR, but it's just a unification of the storage.
17:08:18 <simons> simons has joined #webdriver
17:08:29 <jgraham> sadym: Next PRs remove the restriction that Element ID has to be a UUID.
17:08:37 <simons> present+
17:08:49 <jgraham> sadym: We propose that it has to be a unique string, but the formatting is implementation defined.
17:08:56 <jgraham> q+
17:09:59 <jgraham> simons: The reason for UUIDs was to ensure that there's no clash, it doesn't matter what the identifier is. Tends to be used on the local end in hashing, so it needs to be unique across reloads. An incremental number per page won't work. UUIDs have the required properties.
17:11:03 <jgraham> jgraham: Also the ID shouldn't have additional internal struture that implementations might try to parse out and depend on
17:12:06 <jgraham> sadym: We were planning to rely on that to share ids between classic and bidi. Our idea was to use backendNodeId, which is a unique per-navigable number that increases, and we'd add a prefix of the navigable. That will avoid some implementation problems for us.
17:12:31 <simons> q+
17:12:44 <patrickangle_> q+
17:13:10 <whimboo> q+
17:13:40 <jgraham> jgraham: That seems a bit worrying. Maybe you could apply a transform that would make the identifier hard to parse, but still retain the information you need.
17:13:43 <jgraham> ack jgraham
17:13:45 <jgraham> ack simons
17:14:47 <jgraham> simons: If we allow identifiers to not be UUIDs, we should fobid the "/" character, because people use these directly in URLs. We can also base64 encode to avoid the internal structure being exposed.
17:14:59 <jgraham> simons: That would make it look like a random string of letters and numbers.
17:15:33 <patrickangle_> q-
17:15:40 <jgraham> sadym: Should we specify that it should be not parseable or not? This PR is mainly about switching away from UUIDs, and we need more than 128bits of information.
17:15:45 <jgraham> ack whimboo
17:16:18 <jgraham> whimboo: I'm worried about session id; we shouldn't change that from a UUID since we depend on that for security
17:16:45 <simons> q+
17:17:09 <jgraham> jgraham: I think this is just about element ids. But maybe there's also a concern if they're guessable
17:17:30 <jgraham> ack simons
17:18:02 <patrickangle_> q+
17:18:04 <jgraham> simons: Element ids have another constraint that not only are they unique but they must be 1:1 with elements
17:18:13 <jgraham> sadym: That was the motivation for this change.
17:18:19 <jgraham> ack patrickangle_
17:20:14 <jgraham> patrickangle_: In this proposal are you thinking that if you ran a bunch of WebDriver tests and then closed the browser and then re-ran the same tests later would you get different element ids the next time, or would they be fully predictable
17:20:49 <jgraham> patrickangle_: I'm concerned that if the element ids were constant between tests, people would write tests that depend on the specific ids, and won't be interoperable.
17:21:09 <jgraham> sadym: It will have an id from the renderer, which will be unique
17:21:55 <jgraham> jgraham: That sounds like there might be a component that people would depend on
17:22:09 <jgraham> simons: This would make it harder to write interoperable tests.
17:22:28 <jgraham> sadym: We could hide it by base64 encoding or similar.
17:22:38 <jgraham> sadym: Do we agree that we don't have to stick to the UUID?
17:23:03 <jgraham> simons: We agree that we don't have to stick to the UUID, but there are properties it gives us that are important, and that's causing concerns
17:24:35 <jgraham> jgraham: I think the concerns would be solved if there was a reversible transformation using some per-session random data (e.g. the session id), because that would prevent just hardcoding expectation.
17:24:42 <jgraham> q?
17:25:59 <jgraham> sadym: Two more PRs, which are technical changes. These both depend on teh Node cache changes, so we should discuss after that's merged.
17:26:11 <jgraham> Topic: Element Origin (for BiDI actions)
17:26:19 <jgraham> GitHub: https://github.com/w3c/webdriver/pull/1653
17:28:24 <sadym> I'll take a look at it
17:28:41 <jgraham> jgraham: New PR for deserializing element origins in classic is up. This allows passing steps in, so that classic can have exactly the same behaviour, but BiDi can use the BiDi serialization. This is blockingn landing actions / input support in BiDi.
17:29:02 <jgraham> Topic: Don't break lines in some blocks by sadym-chromium
17:29:11 <jgraham> GitHub: https://github.com/w3c/webdriver-bidi/pull/208
17:30:31 <jgraham> sadym: This PR adds a restriction to not add breaks in specific markdown constructs to make it easier to search in the markdown. We've added some tooling to help enforce this. This PR will involve lots of editing changes to the spec, so it would be nice to land it soon to avoid the need to rebase it and other PRs.
17:31:43 <jgraham> jgraham: I will try to look at that. We'll need to coordinate to avoid conflicts when landing
17:32:09 <jgraham> Topic: Update spec to align with HTML changes
17:32:19 <jgraham> GitHub: https://github.com/w3c/webdriver-bidi/issues/91
17:37:20 <jgraham> jgraham: The HTML spec has been updated with navigables taking on the role of "things that can be navigated" which we previously called [Browsing] Contexts. Proposal is that we use the `context` name in parameters to refer to a navigable and document that it's a legacy feature. For cases where we really want to refer to a specific document/window we could use the sharedId of the Document. Then a
17:37:26 <jgraham> question is if we're OK with keeping the `browsingContext` module name, given that it doesn't really mean that, or if we think it's worthwhile to change it now.
17:37:34 <whimboo> q+
17:37:47 <jgraham> ack whimboo
17:38:08 <simons> q+
17:38:12 <jgraham> whimboo: Would it be possible to have a context module and some kind of alias to keep compatibility for a while?
17:38:22 <jgraham> whimboo: Especially for events.
17:39:12 <sadym> q+
17:39:14 <jgraham> jgraham: I think it's theoretically possible, but it might be a lot of effort; not sure if it would be worthwhile
17:39:17 <jgraham> ack simons
17:39:40 <jgraham> simons: I think there are few enough implementations that we could do the rename now and it would be reasonably safe.
17:39:49 <jgraham> ack sadym
17:39:51 <whimboo> q+
17:40:15 <jgraham> sadym: From our perspective we can change the naming, the question is what's a good naming.
17:41:08 <jgraham> jgraham: context in parameters, or browsingContext the module name?
17:41:55 <jgraham> sadym: browsingContext in the module name is confusing
17:42:08 <jgraham> ack whimboo
17:42:33 <jgraham> whimboo: How much of BiDi is already shipping in Selenium? Could that cause problems if browsers change?
17:43:37 <jgraham> simons: We ship every six weeks. The functionality isn't being used much yet, so I think it will be fine to make a change now. We can communicate the information to users if needed. It's not ideal, but it's not yet in heavy use and it's still marked as experimetnal, so people should be able to upgrade quickly.
17:43:53 <jgraham> whimboo: Each browser should try to do this change at the same time.
17:44:29 <jgraham> simons: That would help, but we can also pin browsers until everyone has made the change. It would be nice for everyone to upgrade at the same time.
17:44:29 <sadym> q+
17:44:32 <jgraham> ack sadym
17:44:53 <jgraham> sadym: There is a way to pin the specific versions of browsers in selenium?
17:45:39 <jgraham> simons: Selenium ships with Selenium-Manager which will download the requested version of a browser if people specify it. It's not like Puppeteer where there's a 1:1 correspondence between the library and the browser.
17:46:36 <jgraham> jgraham: Sounds like if we made the change now we could all agree to ship in the new year. But we need to agree a name.
17:47:44 <jgraham> whimboo: What are the options?
17:48:07 <jgraham> jgraham: context, page, …
17:48:29 <jgraham> whimboo: navigable might not be stable over time, context seems pretty generic
17:49:33 <jgraham> jgraham: I will write this up on the PR
17:49:43 <sadym> target
17:49:55 <sadym> q+
17:50:54 <jgraham> Topic: Using handle and sharedId in the same request?
17:51:06 <jgraham> GitHub: https://github.com/w3c/webdriver-bidi/pull/180
17:51:09 <sadym> https://github.com/w3c/webdriver-bidi/pull/180#discussion_r1048476526
17:52:01 <jgraham> sadym: I get a Node from evaluate and then I send the same node as an argument to callFunction in a sandbox: what should happen? Should we fail?
17:52:18 <jgraham> simons: The local end won't know the two ids refer to the same element.
17:53:20 <jgraham> simons: sharedId will be the same, but handle depends on the sandbox. Do we want to allow having both handle and sharedId in the argument to the function? In a sandbox the handle won't be valid but the sharedId will still be valid. How should we handle that?
17:53:44 <jgraham> simons: What's the expected behaviour from a user? They would expect that the command would work.
17:54:06 <jgraham> q+
17:54:10 <jgraham> ack sadym
17:54:36 <jgraham> simons: We should look at this from a user point of view and figure out what they'd expect to happen in reasonable cases.
17:55:25 <jgraham> sadym: As a user I'd expect I can reuse the data I got over the wire directly in a different realm and ignore the fact that the handle doesn't resolve in the other realm.
17:56:50 <whimboo> q+
17:59:41 <jgraham> jgraham: In this case it seems like just looking at sharedId will probably match user expectations. But it leads to weird edge cases where the data doesn't match. The biggest question is whether this kind of structural typing could lead us into difficulties in the future where there isn't such an obvious choice. If we set the precendent now that we're going to go with a DWIM design we might regret not
17:59:47 <jgraham> being more strict later on.
17:59:56 <jgraham> ack jgraham
18:00:02 <jgraham> ack wimboo
18:00:06 <jgraham> ack whimboo
18:00:46 <jgraham> whimboo: This problem only occurs if you request ownership of the Node. Otherwise we only have sharedId. So you'd need to disown the element in the original realm later on.
18:01:38 <jgraham> RRSAgent: make minutes
18:01:38 <RRSAgent> I have made the request to generate https://www.w3.org/2022/12/14-webdriver-minutes.html jgraham
18:04:29 <simons> simons has joined #webdriver
18:07:47 <simons> simons has joined #webdriver
19:09:53 <gsnedders> is it expected that I'm a member of the WG and not a contributor on GitHub? https://github.com/orgs/w3c/teams?query=members%3Ame makes it look like I'm not a member of any team derived from the W3C group? (cc sideshowbarker, maybe?)
20:21:51 <jgraham1> Expected by whom?
20:22:14 <jgraham1> I didn't think we had teams derived from W3C groups, so if we do that's news
20:33:01 <Zakim> Zakim has left #webdriver
22:03:43 <karlcow_> karlcow_ has joined #webdriver
22:09:16 <Mike5Matrix> <gsnedders> "is it expected that I'm a member..." <- I think we have no mechanism for auto-populating teams based in WG membership. At least I know I've always just created and populated teams manually. The only Github integration I can think of that's WG-aware is the IPR-checker bot that runs when you submit a PR. That knows whether you're a member of the WG
23:39:54 <gsnedders> <Mike5Matrix> "I think we have no mechanism for..." <- I thought that was how https://github.com/orgs/w3c/teams/w3c-group-32061-members was maintained 🤷
23:47:16 <Mike5Matrix> <gsnedders> "I thought that was how https://..." <- Ah yeah, you're right. But I've personally at least never thought about using those control push access for a repo. I don't think they still need to be manually associated for that. Or maybe there's some automation for it that I'm not aware of (but should be...)
23:49:42 <Mike5Matrix> That said, I guess some groups may not want everybody in the group to have push access to their repo
23:52:00 <gsnedders> Oh for sure, I was just surprised I couldn't label issues in the WebDriver repo ☹️