16:02:39 RRSAgent has joined #webdriver 16:02:39 logging to https://www.w3.org/2022/06/08-webdriver-irc 16:02:50 RRSAgent: make logs public 16:02:59 present+ 16:03:01 present+ 16:03:08 present+ 16:03:14 present+ 16:03:20 Meeting: WebDriver 16:03:31 Agenda: https://www.w3.org/wiki/WebDriver/2022-06-BiDi#Agenda 16:03:47 brwalder has joined #webdriver 16:03:52 present+ 16:04:03 present+ 16:04:43 present+ 16:05:06 Chair: foolip 16:05:13 ScribeNick: jgraham 16:05:49 Topic: URL and children fields for browsingContext.contextCreated 16:06:03 github https://github.com/w3c/webdriver-bidi/issues/220 16:06:11 Github: https://github.com/w3c/webdriver-bidi/issues/220 16:06:42 foolip: Looks like we just took the same parameters as for another event, but children and url seem to always have the same value, can we simplify? 16:06:43 q? 16:06:45 q+ 16:06:55 ack jgraham 16:08:58 jimevans has joined #webdriver 16:09:08 jgraham: This event can also be emitted when we subscribe to the event for an existing context. So url can be non-null but children is always null. We could have a single event for all the contexts when you subscribe. 16:09:23 whimboo: Why do we have to emit the events when you susbscribe? 16:11:13 q+ 16:11:14 q? 16:11:38 present+ 16:12:26 jgraham: We chose the current design to allow the client to just listen to the contextCreated events and be up to date with the current state of the browser in a race-free way. Also similar to CDP. Could just emit one event per top-level context with children, which would be less traffic but also different to the events you would have got if you'd already subscirbed when the contexts were first created. 16:12:32 ack foolip 16:13:16 foolip: Focusing on URL. If we want to have a "replay the events model" then they would all have been about:blank and then there would have been navigation events. Would you get all of those events? 16:14:07 jgraham: No. It's hard to replay navigation events. 16:15:36 foolip: URL is only useful in replay case, which is going to be a less-used codepath. Also replaying navigation isn't going to make things better. Think we should discuss this more in the issue. We need to answer: if we make a change here, do we need to change replaying at all? For children, can we get rid of it entirely since it's always null in the current spec. 16:16:42 q+ 16:17:01 jgraham: Populating 'children' rather than just having one event per browsing context would make the protocol less chatty. 16:17:12 q? 16:17:41 jgraham: Just for the replay case. 16:19:08 jdescottes: In firefox devtools we have similar APIs for this. Something that either returned a single browsing context or tree it would be harder to use. Knowing that it's always one browsing context will make the consumer easier to write. For URL it's similar; existing events are different from new ones. You would need to get the URL from a different endpoint. 16:19:31 Topic: Actions changes 16:19:49 Github: https://github.com/w3c/webdriver-bidi/pull/175 16:20:18 q? 16:20:28 ack jdescottes 16:23:22 q+ 16:25:47 jgraham: Two PRs open for WebDriver that are needed to unblock landing input actions in BiDi. First is just making input state per top-level context which we already discussed. Second is adjusting the serialization of Element Origin, adding a form like {type: "element", sharedId: "id"} in addition to the webelement reference deswign from classic. Propsoal is to support both in classic and just new form 16:25:53 in bidi. 16:26:22 simonstewart: Do I understand that there will be two ways to encode an element in classic? 16:27:09 simonstewart: The serializers don't care about which command is being used. They just throw the representation of an element in. 16:28:35 simonstewart: tldr multiple ways to represent an element in a spec is confusing. Makes it harder to reformulate classic on top of bidi. 16:31:08 jgraham: I think all the changes here are in remote ends, not for clients. 16:31:28 simonstewart: How do we represent an element in classic/bidi so that they can be used? 16:34:20 jgraham: We currently use different serializations in general. Carving out an exception for elements is possible, but would be a very special case. 16:34:46 simonstewart: Want to reuse actions. Don't want to make clients make unnecessary changes. 16:35:16 jimevans: Overhead for clients to support classic and BiDi is higher if we update the element representation. 16:35:21 q? 16:35:27 q- 16:36:30 simonstewart: Let's follow up on this outside the meeting. 16:36:53 Topic: Ownership of data passed back from events 16:37:02 Github: https://github.com/w3c/webdriver-bidi/issues/214 16:38:32 q? 16:38:48 foolip: Related to ownership of values returned from script evaluation commands. For those we have a model where you can opt in to getting into ownership. For events we don't have an opt-in mechansim, so you can't keep these alive or guarantee to access them later. Could add an option in ssession.subscribe which allows to opt-in to ownership. 16:38:53 q+ 16:39:11 ack jgraham 16:43:08 jgraham: CDP has strong ownership here by default, and there's a magic object group that you use to release all these handles. We shouldn't do that; with better object serialisation you don't always need to take a strong reference. We probably don't want to use session.subscribe because that can refer to lots of commands / modules. Could have module-level config commands or something. 16:44:13 foolip: Puppeteer seems to leak these by default, so that suggests we don't want to adopt the same design. Is the proposal to add a command like `log.setOwnership`? 16:44:26 jgraham: Maybe log.configure({ownership}) 16:44:39 Topic: Handling of sourcemaps 16:44:47 Github: https://github.com/w3c/webdriver-bidi/issues/213 16:47:05 jdescottes: Source maps: This came up because we want to clean up devtools code that handles this. So we were thinking about whether this is also useful for BiDi. Might be more useful for devtools-like consumers. But can see value in stack traces that refer to original code locations rather than minified ones. Any interest in this? Two possible modes: could auto-translate stack traces or have specific 16:47:11 commands for translating source maps. Doing nothing puts lots of work onto clients that want to do this. Looking for early feedback on prior art and requirements. 16:47:25 q+ 16:48:17 foolip: We have source maps in Chrome devtools too, we should consult them on this issue and see how it maps to what our devtools does. I'll do that. 16:48:34 ack foolip 16:49:10 jdescottes: I can also explain how we consume them in firefox devtools. No pressing need to resolve the issue, but it would be useful to get that input. 16:49:32 q? 16:49:52 foolip: I will ask Mathias 16:50:08 Topic: Backlog of open GitHub issues that need discussion 16:50:28 whimboo: I created this query to ensure we don't forget about topics 16:50:40 whimboo: We could pick one and look at it. 16:50:59 foolip: I like this idea and we could make it a normal part of the agenda. 16:51:24 foolip: "type" argument of "browsingContext.create" should be optional looks interesting 16:51:38 Topic: "type" argument of "browsingContext.create" should be optional 16:51:42 Github: https://github.com/w3c/webdriver-bidi/issues/193 16:53:03 q? 16:53:06 whimboo: Currently if you create a new browsing context you have to specify "tab" or "window". In classic this is optional and remote end can select what's best. BiDi can always ignore the argument when it doesn't work anyway, so making it optional would just invoke the implemenation-specific fallback logic always 16:53:44 foolip: Say "do tab if you can do tab, otherwise do window"? 16:54:26 q? 16:54:31 foolip: This sounds familiar. It makes a lot of sense to me that you might not really care what kind it is. 16:55:25 foolip: Seems like a good idea to have a defined order of the options, so you probably get the same behaviour in different browsers in the same kind of windowing environment 16:55:52 whimboo: More likely to be able to do a tab, since that will work on mobile. 16:56:04 q? 16:56:06 foolip: Browser might not support tabs at all of course. 16:56:35 foolip: Seems like we have agreement, someone should make a PR 16:57:30 RRSAgent: Make minutes 16:57:30 I have made the request to generate https://www.w3.org/2022/06/08-webdriver-minutes.html jgraham 16:58:57 github-bot: end topic 16:59:04 RRSAgent, bye 16:59:04 I see no action items