Meeting minutes
RRSAgent: make logs public
RRSAgent: make minutes
WebDriver Build fixups
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.
sadym: I'm happy to review this, but I'm not a formal approver for WebDriver
Simon: I an approve
jgraham: We don't have codeowners any more
sadym: I don't have enough access to do reviews.
jgraham: We should give sadym permissions to do reviews
shared IDs
github: https://
sadym: PR with Node cache on the WebDriver spec, so we don't have different caches for Element, ShadowRoot.
sadym: I haven't looked at this PR, but it's just a unification of the storage.
sadym: Next PRs remove the restriction that Element ID has to be a UUID.
sadym: We propose that it has to be a unique string, but the formatting is implementation defined.
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.
jgraham: Also the ID shouldn't have additional internal struture that implementations might try to parse out and depend on
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.
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.
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.
simons: That would make it look like a random string of letters and numbers.
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.
whimboo: I'm worried about session id; we shouldn't change that from a UUID since we depend on that for security
jgraham: I think this is just about element ids. But maybe there's also a concern if they're guessable
simons: Element ids have another constraint that not only are they unique but they must be 1:1 with elements
sadym: That was the motivation for this change.
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
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.
sadym: It will have an id from the renderer, which will be unique
jgraham: That sounds like there might be a component that people would depend on
simons: This would make it harder to write interoperable tests.
sadym: We could hide it by base64 encoding or similar.
sadym: Do we agree that we don't have to stick to the UUID?
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
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.
sadym: Two more PRs, which are technical changes. These both depend on teh Node cache changes, so we should discuss after that's merged.
Element Origin (for BiDI actions)
GitHub: https://
<sadym> I'll take a look at it
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.
Don't break lines in some blocks by sadym-chromium
GitHub: https://
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.
jgraham: I will try to look at that. We'll need to coordinate to avoid conflicts when landing
Update spec to align with HTML changes
GitHub: https://
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
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.
whimboo: Would it be possible to have a context module and some kind of alias to keep compatibility for a while?
whimboo: Especially for events.
jgraham: I think it's theoretically possible, but it might be a lot of effort; not sure if it would be worthwhile
simons: I think there are few enough implementations that we could do the rename now and it would be reasonably safe.
sadym: From our perspective we can change the naming, the question is what's a good naming.
jgraham: context in parameters, or browsingContext the module name?
sadym: browsingContext in the module name is confusing
whimboo: How much of BiDi is already shipping in Selenium? Could that cause problems if browsers change?
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.
whimboo: Each browser should try to do this change at the same time.
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.
sadym: There is a way to pin the specific versions of browsers in selenium?
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.
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.
whimboo: What are the options?
jgraham: context, page, …
whimboo: navigable might not be stable over time, context seems pretty generic
jgraham: I will write this up on the PR
<sadym> target
Using handle and sharedId in the same request?
GitHub: https://
<sadym> https://
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?
simons: The local end won't know the two ids refer to the same element.
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?
simons: What's the expected behaviour from a user? They would expect that the command would work.
simons: We should look at this from a user point of view and figure out what they'd expect to happen in reasonable cases.
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.
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
being more strict later on.
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.
RRSAgent: make minutes