15:55:36 <RRSAgent> RRSAgent has joined #webdriver
15:55:40 <RRSAgent> logging to https://www.w3.org/2026/01/15-webdriver-irc
15:55:54 <AutomatedTester> Chair: David Burns
15:56:00 <AutomatedTester> Scribe: David Burns
15:56:06 <AutomatedTester> scribenick: automatedtester
15:57:21 <AutomatedTester> rrsagent,  set logs world-visible
15:57:40 <jgraham> jgraham has joined #webdriver
15:57:50 <AutomatedTester> Meeting: Browser Testing and Tools WG - 15 Jan
15:58:01 <AutomatedTester> Agenda: https://www.w3.org/wiki/WebDriver/2026-01-BiDi
15:58:03 <AutomatedTester> present+
15:58:13 <AutomatedTester> RRSAgent, make minutes
15:58:14 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/15-webdriver-minutes.html AutomatedTester
16:00:46 <whimboo> whimboo has joined #webdriver
16:01:07 <shs> shs has joined #webdriver
16:01:37 <lauromoura> lauromoura has joined #webdriver
16:01:57 <orkon> orkon has joined #webdriver
16:02:11 <jimevans> jimevans has joined #webdriver
16:02:37 <jimevans> present+
16:03:02 <orkon> present+
16:03:22 <sasha> sasha has joined #webdriver
16:03:22 <shs> shs has joined #webdriver
16:03:31 <sasha> present+
16:04:45 <jdescottes> jdescottes has joined #webdriver
16:04:58 <lauromoura> present+
16:05:02 <jdescottes> present+
16:05:52 <shs> present+
16:07:30 <whimboo> present+
16:07:38 <orkon> present+
16:07:40 <AutomatedTester> Topic: Extend log.entryAdded types to more than just console API and Javascript errors
16:07:51 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/149
16:08:07 <hbenl> hbenl has joined #webdriver
16:08:27 <AutomatedTester> whimboo: This is about having better characterisation of types or logging
16:08:41 <AutomatedTester> ... we currently only have console and JS errors
16:08:59 <AutomatedTester> ... for CDP for logentry types is much wider than what we have
16:09:16 <hbenl> hbenl has joined #webdriver
16:09:16 <jdescottes> jdescottes has joined #webdriver
16:09:16 <shs> shs has joined #webdriver
16:09:16 <sasha> sasha has joined #webdriver
16:09:16 <orkon> orkon has joined #webdriver
16:09:16 <lauromoura> lauromoura has joined #webdriver
16:09:16 <whimboo> whimboo has joined #webdriver
16:09:16 <jgraham> jgraham has joined #webdriver
16:09:16 <github-bot> github-bot has joined #webdriver
16:09:16 <jamesn> jamesn has joined #webdriver
16:09:16 <AutomatedTester> AutomatedTester has joined #webdriver
16:09:16 <jcraig> jcraig has joined #webdriver
16:09:16 <rakuco> rakuco has joined #webdriver
16:09:16 <foolip> foolip has joined #webdriver
16:09:43 <AutomatedTester> ... this can lead to differences between browsers.
16:10:07 <AutomatedTester> ... the question is what type of errors can we support. We can see what google can do with CDP
16:10:40 <sadym> present+
16:10:41 <AutomatedTester> ... but it would be good to see what the other clients would want. We can do this in an incremental way so don't need to do all of them
16:10:44 <sadym> q+
16:10:52 <AutomatedTester> ack next
16:11:59 <AutomatedTester> sadym: we are fine with extending the logs in chrome. There is some functionality in puppeteer that shows the owner of the error. We can't do this in bidi but in CDP you can have a handle of the object that caused the error
16:12:10 <AutomatedTester> ... this could be a different topic to discuss maybe
16:12:11 <AutomatedTester> q?
16:13:06 <AutomatedTester> Consensus: We are happy to extend this.
16:13:39 <AutomatedTester> Topic: Scroll Into View [Actions]
16:13:51 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/544
16:14:16 <AutomatedTester> hbenl: we want to bring in an action to scroll and element into view
16:14:37 <AutomatedTester> ... this is currently not able to be done in actions
16:15:13 <AutomatedTester> ... This is currently done by default in playwright. They don't use a DOM api, they use a CDP method for this
16:15:57 <AutomatedTester> ... their scroll can do text nodes and display nodes and can also handle the which part of the element needs to be in the view port
16:16:34 <AutomatedTester> ... though they do sometimes us the DOM API. If the first way doesn't work then they use DOM method to take advantage of the alignment options
16:16:48 <AutomatedTester> ... hoping that the elemtn will eventually be visible
16:17:00 <AutomatedTester> ... CDP doesn't have the alignment methods
16:17:13 <AutomatedTester> ... q1: Do we want this action?
16:17:27 <AutomatedTester> ... q2: what options do we want to have on this action
16:18:45 <AutomatedTester> ... q3: do we want to have a behaviour option, alignment options, container options, also if needed to have an option to have fallback to try again to bring it into view
16:18:55 <AutomatedTester> q?
16:19:04 <jgraham> q+
16:19:06 <AutomatedTester> ack next
16:19:34 <AutomatedTester> jgraham: there is one more question, do we need a separate top level method here or should this be part of actions?
16:19:51 <shs> q+
16:19:53 <AutomatedTester> ... if we put it in actions we can interleve it with other actions
16:19:53 <sadym> q+
16:20:16 <AutomatedTester> ... it's not related to user actions...
16:20:40 <AutomatedTester> hbenl: if you have multiple clicks in an action chain you want to scroll them into view before the next actions
16:20:42 <AutomatedTester> q?
16:20:45 <AutomatedTester> ack next
16:21:23 <AutomatedTester> shs: I think there are cases to have it in actions. There could be a drag and drop where the first element is in view but the 2nd option isnt
16:21:36 <AutomatedTester> ... and we discussed this yesterday with double click
16:21:54 <jimevans> q+
16:22:12 <AutomatedTester> ... and in the "do what I mean" click we will want to have the element pulled into view before the click so that we can have something like what we have in the classic spec
16:22:15 <AutomatedTester> ack next
16:22:38 <AutomatedTester> sadym: I am afraid we will have race conditions as the scroll could take a while
16:22:48 <orkon> q+
16:23:02 <AutomatedTester> ... my concern is we can have race conditions with other actions
16:23:06 <AutomatedTester> ack next
16:23:30 <jgraham> q+
16:23:51 <AutomatedTester> jimevans: I believe that in classic spec that for the elemnet click we have auto scrolling. Are there cases where the element can't be scrolled into view?
16:24:00 <whimboo> https://w3c.github.io/webdriver/#element-click step 5 is scroll into view the element
16:24:16 <AutomatedTester> ... as in they can't be scrolled into view by a user but can be done via execute script
16:24:56 <AutomatedTester> .... <describes a scenario about overflow in a container where a person can't but JS can>
16:25:17 <AutomatedTester> ... if we are doing this we need to make sure that we handle this case
16:25:25 <AutomatedTester> q?
16:25:25 <AutomatedTester> ack next
16:25:29 <sadym> q+
16:26:32 <AutomatedTester> orkon: I think the important part of the method is "if needed'. This isn't always going to be needed. We probably need to have this as it's in playwright/puppeteer? Should it be in the client or protocol?
16:26:55 <AutomatedTester> ... I don't think we need to have a top level method as people can just call execute script
16:27:00 <AutomatedTester> q?
16:27:02 <AutomatedTester> ack next
16:27:31 <orkon> q+
16:27:35 <sadym> q+ to ask if extending https://www.w3.org/TR/webdriver-bidi/#cddl-type-inputelementorigin with bool param "scrollIfNeeded" be sufficient?
16:28:04 <AutomatedTester> jgraham: re: race conditions. In other actions we have a way to extend actions ticks so it seems reasonable way to be able to handle this without
16:28:27 <AutomatedTester> ... as for top level or action, I think just having it in actions is sufficient as you can send an action with just a scroll
16:28:33 <AutomatedTester> ack next
16:28:34 <Zakim> sadym, you wanted to ask if extending https://www.w3.org/TR/webdriver-bidi/#cddl-type-inputelementorigin with bool param "scrollIfNeeded" be sufficient?
16:29:11 <AutomatedTester> sadym: will it be sufficient to add a param scrollIfNeeded?
16:29:14 <jgraham> q+
16:29:17 <AutomatedTester> ack next
16:29:42 <AutomatedTester> orkon: I think there could be a challenge knowing if a scroll has completed
16:29:57 <AutomatedTester> ... there could be things that happen during a scroll
16:30:15 <AutomatedTester> ... there could be issues if we are trying to do a smooth scroll.
16:30:44 <AutomatedTester> ... I think there could a case to scroll the element or a page and that could be a top level method
16:30:47 <AutomatedTester> q?
16:30:48 <AutomatedTester> ack next
16:31:14 <orkon> q+
16:31:15 <AutomatedTester> jgraham: I think limitations apply equally if it is actions or a top level method
16:31:30 <AutomatedTester> ... we would need to define "done"
16:32:02 <whimboo> q+
16:32:47 <AutomatedTester> ... the other thing is if it should be a param? I agree with orkon that it should be able to do this independently and it could have it work
16:32:58 <AutomatedTester> ... I think it should be a top level method
16:33:24 <jimevans> q+
16:33:30 <AutomatedTester> ... and should it be an immediate or smooth scroll
16:33:32 <AutomatedTester> q?
16:33:35 <AutomatedTester> ack next
16:34:13 <jimevans> q-
16:34:28 <AutomatedTester> orkon: the diff is with actions or top level is that one can wait for the scroll to happen. I think that we can have a way
16:34:44 <jgraham> scribe+
16:34:51 <jgraham> ack next
16:35:29 <jgraham> orkon: The other part is whether we're prepared to spec scrollIntoViewIfNeeded, that seems important to the use cases
16:36:26 <jgraham> whimboo: If we're unsure that we can check if the scroll has ended should we make it instant-only for actions? Smooth is definitely something we want to have, but classic only has instant. People are asking for smooth
16:36:28 <jgraham> q+
16:36:35 <jgraham> ack next
16:38:16 <hbenl> q+
16:38:25 <whimboo> q+
16:38:47 <jgraham> jgraham: In both actions and a top-level command we have to decide when the scroll is complete; I think it's fine to have smooth scroll for both. Are there concerns with specifying the if needed part for scrolling?
16:38:51 <jgraham> ack next
16:40:28 <jgraham> hbenl: I wanted to reiterate the use case of specifying which part of the element should be in view e.g. a rectangle that's inside the element. This is especially important for the if needed part e.g. for drag and drop you might want a specific rect that's in-view. I think at least a position and probably a rect are needed.
16:40:34 <jgraham> ack next
16:42:39 <jgraham> jgraham: I think that's reasonable; it's a small extension of what we already support for pointerMove where you can specify a point relative to an element. Being able to specify where the element ends up in the viewport would be more novel.
16:44:02 <jgraham> q+
16:44:34 <AutomatedTester> whimboo: if there are elements that people try move to elements that are a text node. do we want to handle the situation where they can move to parent them scroll them but there are cases where it is too large so what do we want to do there?
16:44:37 <AutomatedTester> ack next
16:44:48 <sadym> q+
16:45:14 <AutomatedTester> jgraham: I think we want to figure a way to get a bonding box for a text node. I am not sure if CSS already handles this for us?
16:45:29 <AutomatedTester> ... I don't think we want to go up to the element to do this
16:45:42 <AutomatedTester> ... I think the requirement is that we move the text
16:45:58 <sadym> q+
16:46:00 <AutomatedTester> whimboo: we could do <describes way to get the position of a text node> to handle this
16:46:04 <AutomatedTester> ack next
16:46:33 <whimboo> as example this might work: document.createRange().selectNodeContents(textNode)
16:46:53 <AutomatedTester> sadym: since we ahve consesus above, do we want a dedicated command for this?
16:48:06 <jimevans> q+
16:48:53 <AutomatedTester> jgraham: I think the consensus above was that it made sense in actions due to use cases and the top level commands can be composed of actions
16:48:58 <AutomatedTester> ack next
16:49:42 <AutomatedTester> jimevans: as a follow up to jgraham . you can't do getBoundingRect on text nodes. Whimboo has given an example in the chat
16:49:53 <AutomatedTester> q?
16:51:14 <orkon> present-
16:51:26 <AutomatedTester> Meeting to continue at 6pm UTC
16:59:41 <Adam_Page> Adam_Page has joined #webdriver
17:00:04 <spectranaut_> spectranaut_ has joined #webdriver
17:59:02 <orkon> orkon has joined #webdriver
18:00:44 <orkon> present+
18:02:25 <AutomatedTester> Topic: Mobile emulation
18:02:27 <tidoust> present+
18:02:33 <AutomatedTester> Github: https://github.com/w3c/webdriver-bidi/issues/772
18:02:33 <sasha> sasha has joined #webdriver
18:03:59 <tidoust> scribe+
18:06:25 <tidoust> sadym: First naive approach would be to make a flag that would be "emulate mobile" whatever that means.
18:06:43 <AutomatedTester> q?
18:06:56 <tidoust> ... All the things that Chromium does when emulating mobile are listed in the issue. We propose to address them individually.
18:07:23 <jgraham> q+
18:07:34 <tidoust> ... and then introduce common device configuration perhaps.
18:07:38 <AutomatedTester> ack next
18:07:54 <tidoust> jgraham: I think dealing with each thing separately makes a lot of sense.
18:08:27 <tidoust> ... I'm not sure it makes a lot of sense to explain what, e.g., Firefox does because that's going to change over time.
18:08:45 <tidoust> ... There may be a way to publish somewhere the set of settings that would take you close to something.
18:09:09 <AutomatedTester> q?
18:09:14 <tidoust> ... I would want to be in control if I wanted to test something, and not let the browser in control and possibly change the interpretation.
18:09:18 <sadym> q+
18:09:24 <AutomatedTester> ack next
18:09:48 <bburg> bburg has joined #webdriver
18:10:16 <tidoust> sadym: The main scenario is for users to emulate specific devices. It would be good to check that Safari and Firefox are working with the settings, as a way not to introduce regressions in tests.
18:10:17 <AutomatedTester> q?
18:10:43 <whimboo> whimboo has joined #webdriver
18:10:43 <tidoust> jgraham: Where would you maintain these configurations?
18:11:19 <tidoust> sadym: First: list of features. We want to make sure we didn't miss anything.
18:11:33 <tidoust> ... Second: list of known devices, but it can be done on the side, perhaps as part of the test suite.
18:12:00 <AutomatedTester> q?
18:12:04 <tidoust> jgraham: OK. First check is to assess whether Firefox is doing the right thing in devtools, then.
18:12:28 <sasha> q+
18:12:37 <jgraham> s/Firefox is doing the right thing in devtools/whether the list in the agenda matches RDM in Firefox devtools/
18:13:15 <tidoust> jdescottes: [going through the list]. Some are not used in Firefox. List needs to be refined, I guess.
18:13:18 <AutomatedTester> ack next
18:13:23 <bburg> q+
18:13:32 <jgraham> ( we don't support client hints at all at the moment )
18:13:52 <tidoust> sasha: The media features are not necessarily bound directly to the mobile mode. Some of them, you can turn on or off in RDM.
18:14:06 <tidoust> ... The scroll by emulation, media features, but not text sizing, etc.
18:14:15 <AutomatedTester> ack next
18:14:25 <jdescottes> q+
18:15:05 <tidoust> bburg: Catching up. Some of the things are confusing to me. In Webkit, WebInspector, there is a way to override things such as accessibility contrast.
18:15:14 <tidoust> ... We don't really know what the device is or not.
18:15:23 <jgraham> q+
18:15:41 <jdescottes> q-
18:15:53 <tidoust> ... It sounds like we're talking about a desktop browser emulating a mobile browser, not a mobile browser directly.
18:16:08 <tidoust> ... Some clarity on what is being solved would be appreciated.
18:16:20 <tidoust> ... Understanding the user scenario would also be super useful.
18:16:33 <tidoust> ... I prefer to use existing capability mechanisms whenever possible.
18:17:06 <tidoust> ... Media stuff, there are lots of things you specifically need. I don't really know the spread of features and needs are.
18:17:41 <AutomatedTester> q?
18:17:50 <tidoust> ... How are we going subfeatures in web pages, I'm interested to know. Are we talking about WebViews? Emulators?
18:17:57 <AutomatedTester> ack next
18:18:05 <jdescottes> q+
18:18:27 <tidoust> jgraham: My understanding is that the use case is basically testing in a desktop browser in such a way that it's a reasonable approximation of a mobile browser.
18:18:59 <tidoust> ... For example, Playwright allows you to tweak the desktop browser to be like a mobile one, but not to be directly a mobile browser.
18:19:30 <tidoust> ... Other slightly problem might be KVM access, which may not be possible.
18:19:51 <AutomatedTester> q?
18:19:53 <sadym> q
18:19:56 <sadym> q+
18:20:00 <AutomatedTester> ack next
18:20:04 <tidoust> ... Goal is to find a sweet spot in the simplicity vs fidelity curve.
18:20:38 <AutomatedTester> q?
18:20:39 <tidoust> jdescottes: I don't believe Firefox RDM mode enables something outside of the list. From that perspective, it does not miss anything.
18:20:58 <AutomatedTester> ack next
18:21:30 <tidoust> sadym: I would like to ask Safari folks to look at the list and see if there's something else.
18:22:14 <AutomatedTester> q?
18:22:23 <tidoust> ... The goal for us is to enable mobile emulation on desktop devices. That's the easiest way for users to have a good perspective on what the site would be on mobile devices.
18:22:29 <tidoust> ... Of course, that's imperfect.
18:22:34 <AutomatedTester> q?
18:23:03 <bburg> I see, so this sounds more like RDM mode options.
18:23:30 <AutomatedTester> topic: Scrollbar emulation
18:23:43 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/pull/1050
18:24:39 <tidoust> sadym: Scrollbar types. We want to allow for switching between classic and overlay scrollbars to emulate mobile devices.
18:25:04 <tidoust> ... With yesterday's discussion in mind, it should perhaps be a dedicated command.
18:25:45 <AutomatedTester> q?
18:25:47 <tidoust> ... I believe the decision here would be: would people support setViewport together with scrollbarType, or should they be separate?
18:26:09 <sasha> q+
18:26:15 <AutomatedTester> ack next
18:27:13 <tidoust> sasha: Setting viewport may not be only about mobile emulation. You would not need to set the scrollbar type in such cases.
18:28:03 <tidoust> ... The setViewport command was introduced early on and doesn't fit the new way we introduce emulation commands these days. List of user contexts and list of browser contexts are missing. Not the same semantics.
18:28:24 <sadym> q+
18:28:29 <tidoust> ... Device pixel ratio would also be changing the screen settings rather than the viewport.
18:28:41 <orkon> q+ desktop systems can have different scrollbar types AFAIK
18:28:43 <tidoust> ... I would want setViewport to only change the viewport and have other settings somewhere else.
18:28:58 <AutomatedTester> q?
18:29:06 <tidoust> q+ orkon to say that desktop systems can have different scrollbar types AFAIK
18:29:11 <AutomatedTester> ack next
18:29:45 <tidoust> sadym: I don't think it belongs to emulation. We're switching the scrollbar type, not emulating some of them.
18:30:05 <tidoust> ... I'm going to add a dedicated comment.
18:30:08 <AutomatedTester> q?
18:30:17 <AutomatedTester> s/comment/command
18:30:18 <tidoust> s/comment/command/
18:30:20 <AutomatedTester> ack next
18:30:21 <Zakim> orkon, you wanted to say that desktop systems can have different scrollbar types AFAIK
18:30:55 <tidoust> orkon: Scrollbar types can be relevant for desktop. I think on Safari, you can change that in the settings in particular.
18:31:12 <AutomatedTester> q?
18:31:14 <whimboo> q+
18:31:19 <AutomatedTester> ack next
18:31:32 <jdescottes> s/Safari/macos/
18:32:03 <tidoust> whimboo: How should we behave by default? The resulting viewport may be different and a test could fail as a result.
18:32:18 <AutomatedTester> q?
18:32:22 <sadym> q+
18:32:26 <AutomatedTester> ack next
18:32:36 <jgraham> q+
18:34:14 <sadym> Currently, it is done by an optional param `scrollbarType` on `browsingContext.setViewport`. One can sspecify it, or keep it default, up to the user
18:34:16 <AutomatedTester> ack next
18:34:46 <tidoust> jgraham: I think the default should be whatever the browser does by default.
18:35:06 <tidoust> ... If you're using it in a scenario where it matters, then you just have to configure that at the start of your test.
18:35:21 <tidoust> ... We shouldn't change anything by default just because we start a WebDriver BiDi session.
18:35:37 <AutomatedTester> q?
18:35:54 <sadym> q+
18:36:00 <AutomatedTester> ack next
18:36:30 <tidoust> sadym: The consensus is to move it to a dedicated command, and to let browsers use their own default.
18:36:39 <AutomatedTester> topic: Text sizing
18:36:47 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/1051
18:37:00 <sadym> the consensus: move it to the dedicated command and allow for setting the default and returning "unsupported" if so
18:37:56 <tidoust> sadym: Minimum readable text size. It's different in different browsers. It tells what is the smallest a readable text can be.
18:38:23 <tidoust> ... I'm going to update the issue description.
18:39:00 <AutomatedTester> q?
18:39:47 <sadym> q+
18:39:55 <AutomatedTester> ack next
18:40:44 <tidoust> sadym: This specification is CSS specification, and it can take a long time to change. Are we fine with landing WebDriver BiDi first with hooks to it and wait for CSS to adopt it?
18:40:57 <jgraham> q+
18:41:05 <tidoust> ... Or do we want to land the BiDi command only when the CSS hooks are approved or pre-approved.
18:41:12 <AutomatedTester> ack next
18:42:04 <sadym> q+
18:42:06 <tidoust> jgraham: I think we'll need to look what implementations do here. I don't know if minimum text size is a good characterization, or if you need text inflation, or if it's more complex than that.
18:42:36 <tidoust> ... I don't know enough details to make a call on this.
18:42:45 <AutomatedTester> ack next
18:43:37 <tidoust> sadym: We want this unified across the browsers. For sure, we have different engines working differently. We can use that command to do additional logic to emulate things further, which isn't required by CSS.
18:43:42 <jgraham> q+
18:43:42 <AutomatedTester> q?
18:43:44 <AutomatedTester> ack next
18:45:05 <tidoust> jgraham: Very quickly, there seem to be 4 different values in the code. The command could be setting mobile text layout for example. By default, the browser has to pick something that is appropriate to the context.
18:45:23 <AutomatedTester> q?
18:45:36 <sadym> q+
18:45:43 <AutomatedTester> ack next
18:46:07 <jgraham> q+
18:46:08 <jdescottes> q+
18:46:17 <AutomatedTester> ack next
18:46:33 <tidoust> sadym: No split between specific answers.
18:46:42 <tidoust> jgraham: That does not seem like a good idea.
18:46:43 <sadym> q+
18:46:56 <tidoust> ... For the font size inflation that browsers do on mobile, that seems fine.
18:47:02 <AutomatedTester> ack next
18:47:06 <tidoust> ... I don't think it should affect other mobile emulation stuff.
18:47:30 <tidoust> jdescottes: If we don't have a strong spec that we can hook into, we should not try to add behavior that only Chrome would implement.
18:47:50 <tidoust> ... I think this command should still do something that can matched to a spec and by all browsers as much as possible.
18:47:53 <AutomatedTester> ack next
18:48:25 <tidoust> sadym: So consensus is to introduce a command, emulateMobileTextLayout with implementation-specific logic behind it.
18:48:34 <AutomatedTester> Topic: Viewport Meta
18:48:56 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/1053
18:49:22 <tidoust> sadym: Another thing that mobile browsers do but do not desktop is the viewport meta tag.
18:49:35 <tidoust> ... I didn't read the issue in details.
18:50:06 <tidoust> s/the issue/the issue that Sam raised/
18:50:16 <AutomatedTester> q?
18:50:18 <sasha> q+
18:50:22 <AutomatedTester> ack next
18:50:46 <tidoust> sasha: That would be fine for us. We do this in RDM as well. We were planning to have it as a feature as well.
18:51:02 <AutomatedTester> q?
18:51:36 <tidoust> AutomatedTester: Consensus: let's do this as a separate command
18:51:43 <AutomatedTester> Topic: Safe area insets
18:51:55 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/1054
18:52:48 <tidoust> sadym: Insets, I'm not sure how well they are supported by all the browsers. It can be the camera area on the phone.
18:53:10 <tidoust> ... It's something that can be emulated, the question is: do we want to have it specified?
18:53:41 <AutomatedTester> q?
18:53:49 <AutomatedTester> q+
18:53:53 <AutomatedTester> ack next
18:54:42 <tidoust> AutomatedTester: I think we probably would want to have something like this. I'm not sure how common people would have it but I can see the watch example being quite useful for people to test on a smaller area.
18:54:59 <AutomatedTester> q?
18:55:01 <sasha> q+
18:55:04 <AutomatedTester> ack next
18:55:35 <tidoust> sasha: Firefox also supports it, so we could add it as well. I'm not sure whether it's a priority at the moment. Maybe in the future.
18:56:22 <tidoust> AutomatedTester: Consensus is we'll look into it at some point.
18:57:21 <AutomatedTester> Topic: Mobile testing - show / hide virtual keyboard
18:57:29 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/1059
18:58:03 <tidoust> jgraham: This has come up out of the interop mobile testing.
18:58:20 <tidoust> ... People want to test in web apps whether the virtual keyboard is hidden or displayed.
18:58:48 <tidoust> ... There's also an API proposal to allow people to show/hide the virtual keyboard.
18:58:56 <sadym> q+
18:59:01 <tidoust> ... It would be useful if WebDriver gave you the control of whether the virtual keyboard is displayed or not.
18:59:11 <tidoust> ... See the current proposal in the issue.
18:59:22 <AutomatedTester> q+
18:59:26 <tidoust> ... Of course, on some platforms, it may not work. UnsupportedOperation in such cases.
18:59:29 <AutomatedTester> ack next
19:00:01 <jdescottes> q+
19:00:41 <tidoust> sadym: Are there any other observable effects on top of navigator.virtualKeyboard and viewport changes?
19:00:57 <tidoust> jgraham: I'm not 100% sure how this integrates with the layout API.
19:00:58 <AutomatedTester> scribe+
19:01:05 <AutomatedTester> q-
19:01:21 <sadym> q+
19:01:21 <tidoust> ... I think that the virtual keyboard is overlaying but I'm not sure that's the case in 100% of all cases.
19:01:50 <AutomatedTester> ack next
19:02:07 <AutomatedTester> jdescottes: I want to mention that we have started working on VK for RDM
19:02:22 <AutomatedTester> ... we have also started working on dynamic toolbars for mobile
19:02:50 <AutomatedTester> ... so I think we should think about handling overlays e.g toolbars or keysboard
19:02:59 <AutomatedTester> jgraham: thats the next topic and I think that's harder
19:03:02 <AutomatedTester> q?
19:03:04 <AutomatedTester> ack next
19:03:37 <AutomatedTester> sadym: I have 2 main concerns
19:04:07 <AutomatedTester> ... on devices taht support it, I don't think there is a mechanism for handling if an element that launches it
19:04:37 <jgraham> q+
19:04:40 <AutomatedTester> ... <missed use case> which is a perfect use case for emulation
19:05:03 <AutomatedTester> ... and for devices that handle this natively it could use the native device and not the emulated device
19:05:48 <AutomatedTester> ack next
19:06:12 <sadym> s/<missed use case>/I don't think there is a scenario when the user expect VK to appear if there are no forms or inputs
19:06:18 <AutomatedTester> jgraham: coming from interop mobile testing, the use cases for devices that have a VK are strong enough
19:06:44 <sadym> q+
19:06:49 <AutomatedTester> ... I think the same API can be used for vk
19:07:14 <AutomatedTester> ... I think that it is a bit much for implementors to have to create their own VK and should just use the system one
19:07:22 <jdescottes> q+
19:07:29 <AutomatedTester> ... however there have been requests for this in RDM
19:07:32 <AutomatedTester> ack next
19:07:49 <jgraham> s/should just use the system one/should be allowed to return unsupported operation if they don't support it/
19:07:56 <AutomatedTester> sadym: to be clear, I don't propose that implemetations have their one
19:08:14 <AutomatedTester> ... it should just create the observable effects
19:08:21 <jdescottes> q-
19:08:36 <AutomatedTester> q?
19:09:15 <orkon> q+
19:09:20 <AutomatedTester> ack next
19:09:29 <jgraham> q+
19:10:35 <AutomatedTester> orkon: I think if we want to run this on real devices that we and have support for VK. I think we should be able to do this already. We have concerns about this being in a dedicated command
19:10:42 <AutomatedTester> ack next
19:11:36 <AutomatedTester> jgraham: I am not sure that I have understood the concerns other than an extra command. It seems like it would be convienent for users to be able to have this. If we don't have it in webdriver then we can't test that API at all
19:12:24 <orkon> q+
19:12:30 <AutomatedTester> ... as for emulations, I think one problem is that a device could have a touch and have emulated a smallers screen and you call vk, should you get a system keyboard or a smaller vk?
19:12:46 <AutomatedTester> ... so should we have a command that only targets the system vk?
19:12:49 <AutomatedTester> ack next
19:13:29 <AutomatedTester> orkon: putting emulation aside, can you clarify where this isn't testable if we can already do it via script evaluation? What is not possible?
19:14:16 <AutomatedTester> jgraham: You end up testing the API with the API. If I use the API, do I get the events. It would be nicer to have a automation command to make sure the events are fired
19:14:21 <orkon> q+
19:14:34 <AutomatedTester> ... that way you can test the side effects without calling the API
19:15:01 <AutomatedTester> ... I don't know if that will be consistent enough between browsers to make sure it was interoperable
19:15:05 <AutomatedTester> ack next
19:16:02 <AutomatedTester> orkon: The API says you can show the keyboard. In practise you need an element to make it work properly. That way we need to have a way to pick an element, make sure it gets focus etc
19:16:22 <AutomatedTester> ... we don't have a way of hiding the VK and the events?
19:16:36 <jgraham> q+
19:16:38 <AutomatedTester> ... so do we need an anchor element?
19:16:41 <AutomatedTester> ack next
19:17:40 <AutomatedTester> jgraham: that is a good question. I don't know if there is something practise if there was a way to trigger the keyboard without having an anchor element?
19:18:01 <AutomatedTester> ... there should be a way to say use this element and set focus and load the vk
19:18:04 <AutomatedTester> q?
19:18:49 <AutomatedTester> bburg: you can use a keyboard on iOS and we won't show the keyboard unless there is a carat for it
19:18:59 <AutomatedTester> q?
19:20:27 <AutomatedTester> consensus: there are cases that are different to the DOM API. If you have a carat, you should freely show/hide the VK. There is something worth pursuing here. jgraham to look into this further
19:20:42 <AutomatedTester> topic: Mobile testing - toggle browser UI state
19:20:52 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/1060
19:21:40 <AutomatedTester> jgraham: This is for testing on mobile browsers that allows us to set a UI state
19:22:05 <AutomatedTester> ... there are bugs on sites between transitions of toolbars
19:22:21 <AutomatedTester> ... this feels more problematic than the previous topic
19:22:46 <AutomatedTester> ... is there a minimal API that we can create here that we can extend in the future
19:23:01 <orkon> q+
19:23:06 <AutomatedTester> ... the API can starts with setting it to visible and then setting it to hidden
19:23:16 <AutomatedTester> ... I am not sure if that is going to be sufficient
19:23:18 <AutomatedTester> q?
19:23:22 <AutomatedTester> ack next
19:24:01 <AutomatedTester> orkon: I am assuming this isn't web exposed and wonder if there is a way to do this via <missed name used>
19:24:14 <orkon> s/<missed name used>/browsingContext.activate
19:24:55 <AutomatedTester> jgraham: this is about showing/hide browser ui. e.g. Firefox for android if you scroll to the top of the page it will show the URL bar
19:25:35 <AutomatedTester> ... having a browser that scrolls in a test can be difficult. It would be easier to have a "show me the browser with the toolbar enabled and then show me without it enabled"
19:25:45 <AutomatedTester> q?
19:25:52 <orkon> q+
19:25:57 <AutomatedTester> ack next
19:26:42 <AutomatedTester> orkon: I am not sure if the implementation would look like? How would the client learn about to set?
19:26:57 <AutomatedTester> ... is there a list of side effects people would expect
19:27:09 <AutomatedTester> ... or get not supported if the browser can't do it
19:27:15 <jgraham> q+
19:27:19 <AutomatedTester> ack next
19:27:35 <AutomatedTester> jgraham: the site would see the viewport changing
19:28:20 <AutomatedTester> ... a site would have an element that would appear in a place when the url is hidden and then jumps up if the URL bar checks its in the correct place
19:28:56 <AutomatedTester> ... they should be able to check the view port and has changed and react accordingly other it could lead to bugs in the site
19:29:06 <AutomatedTester> q?
19:29:29 <orkon> q+
19:29:33 <AutomatedTester> ack next
19:30:02 <AutomatedTester> orkon: I think this sounds useful but I think we need to do more research to understand the problem better
19:30:02 <jgraham> q+
19:30:08 <AutomatedTester> ack next
19:30:29 <AutomatedTester> jgraham: I think this is exposed in CSS via viewport units
19:31:20 <orkon> q+
19:31:25 <AutomatedTester> ... I think there already understanding on the platform for how to do deal with this and it makes sense for webdriver to understand so that we can test this better
19:31:29 <AutomatedTester> ack next
19:32:37 <AutomatedTester> rrsagent, make minutes
19:32:38 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/15-webdriver-minutes.html AutomatedTester
19:33:34 <AutomatedTester> orkon: so this would only be for what is supported on the devices and not for emulation.
19:33:57 <AutomatedTester> jgraham: I think it would be good to start with what is on the device but there may be usecases for emulation at some point
19:34:30 <AutomatedTester> consensus: Leaning towards adding this but more research to be done
19:34:47 <AutomatedTester> topic: Log argument ownership
19:35:25 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/214
19:36:02 <AutomatedTester> sadym: with the discussion around log entry
19:36:33 <AutomatedTester> ... at the moment when logEntry added event is sent the owner is always null
19:36:51 <AutomatedTester> ... it would be better to have better ownership of the error
19:37:21 <AutomatedTester> ... the only issue is that if they want the error they need to make sure that if it is no longer being used they will need to clean it up
19:37:32 <AutomatedTester> ... so what is the best way for us to handle this
19:37:39 <AutomatedTester> q?
19:38:06 <AutomatedTester> q?
19:38:07 <sadym> q+
19:38:12 <AutomatedTester> ack next
19:38:41 <AutomatedTester> sadym: is the log.config with the ownership details is the one that we would agree on? This was proposed by jgraham
19:38:47 <sadym> `log.configure({ownership})`
19:39:18 <jgraham> q+
19:39:22 <AutomatedTester> ack next
19:39:23 <sadym> perhaps with `contexts` and `userContexts`
19:39:57 <AutomatedTester> jgraham: I think the reason we landed there before was because of the reasons you mentioned
19:40:11 <AutomatedTester> ... as it could to leaking of objects
19:40:17 <sadym> q+
19:40:36 <AutomatedTester> ... for devtools console, if you wanted to have those items then you would want to keep them alive
19:40:54 <AutomatedTester> ... chrome keeps them alive until they are discarded
19:41:23 <AutomatedTester> ... we didn't want the user to be having to know when to free objects
19:41:38 <AutomatedTester> ... we have avoided this type of config command in the protocol
19:41:49 <AutomatedTester> ... it's not ideal as it create global state
19:42:21 <AutomatedTester> ... with logging, the other use case is to filter waht log events to send (e.g. debug, info)
19:42:31 <AutomatedTester> ... I don't have a better idea that 4 years ago
19:42:57 <AutomatedTester> ... from a client you are setting flobal state. You can't isolate state
19:43:07 <AutomatedTester> ack next
19:43:33 <AutomatedTester> sadym: the lifetime of the object is not longer than the lifetime of the realm
19:43:44 <AutomatedTester> ... we can config via context and userContext
19:43:55 <jgraham> q+
19:44:00 <AutomatedTester> ... this would allow for precise enough control
19:44:14 <AutomatedTester> ... in puppeteer we would enable it it globally
19:44:19 <AutomatedTester> ack next
19:44:40 <AutomatedTester> jgraham: I agree that scoping it to a user context is useful
19:44:58 <AutomatedTester> ... but there can be a case where a test fixture decided to own objects
19:45:18 <AutomatedTester> ... and the test redoes the config which can cause problems
19:45:41 <AutomatedTester> ... or a test one level errors but the fixture wants another
19:45:52 <sadym> q
19:45:52 <AutomatedTester> ... that is the isolation that I had in mind
19:45:55 <sadym> q+
19:46:22 <AutomatedTester> jgraham: I guess puppeteer doesn't give people the choice and just does it globally but that's not ideal
19:46:24 <AutomatedTester> q?
19:46:27 <AutomatedTester> ack next
19:47:23 <AutomatedTester> sadym: it is related to any other state of the browser that can be controlled by 2 different clients. It is a valid concern but we need to make sure that people will only do that if they have a reason
19:48:09 <AutomatedTester> ... or we turn it on for everyone and don't allow them to configure
19:48:48 <AutomatedTester> jgraham: no. I think the default is that objects get GC'ed unless they ask for it
19:48:49 <jimevans_> jimevans_ has joined #webdriver
19:48:51 <jdescottes> q+
19:48:58 <AutomatedTester> ack next
19:49:01 <sadym> q+
19:49:20 <orkon> orkon has joined #webdriver
19:49:25 <AutomatedTester> jdescottes: would it help to disarm? everything for log related?
19:49:31 <AutomatedTester> ack next
19:49:37 <jdescottes> s/disarm/disown/
19:49:38 <jgraham> s/disarm/disown/
19:50:24 <AutomatedTester> sadym: I wonder what firefox does when it has devtools open? Do you GC it? and for Safari?
19:50:43 <jdescottes> q+
19:50:50 <AutomatedTester> ... or is GC'ed when the realm is destroyed
19:50:55 <AutomatedTester> ack next
19:51:07 <AutomatedTester> jdescottes: we GC on navigation
19:51:13 <sadym> q+
19:51:17 <AutomatedTester> ack next
19:51:39 <AutomatedTester> sadym: which means you configure to global for devtools
19:52:00 <AutomatedTester> jdescottes: yes for devtools but bidi might be different
19:52:07 <AutomatedTester> sadym: and for classic?
19:52:13 <AutomatedTester> jdescottes: we don't for classic
19:52:19 <AutomatedTester> q?
19:53:12 <AutomatedTester> sadym: I don't think it's much to wait for the realm to be destroyed. It can be default to global or have a configure
19:53:21 <AutomatedTester> jgraham: I would prefer the configure
19:53:27 <orkon> q+
19:53:38 <AutomatedTester> sadym: the consensus is for us to have a configure for this
19:53:40 <AutomatedTester> ack next
19:54:02 <AutomatedTester> orkon: it might also be a good place to set the log levels that you expect to get
19:54:09 <AutomatedTester> q?
19:54:48 <AutomatedTester> action: Create a new issue to handle the log levels as a config
19:55:12 <AutomatedTester> topic: Status of the WebDriver BiDi roadmap planning spreadsheet
19:56:01 <sadym> q+
19:56:21 <AutomatedTester> whimboo: we have this spreadsheet for the bidi. I was wondering if it was worth maintaining but it's not always up to date or should we do things via github?
19:56:26 <AutomatedTester> ack next
19:57:13 <AutomatedTester> sadym: I haven't looked at this in ages. I think github should be a source of truth
19:57:22 <AutomatedTester> ... and have a mechanism for clients to use
19:57:29 <orkon> q+
19:57:32 <AutomatedTester> ack next
19:57:38 <sadym> q+
19:58:09 <AutomatedTester> orkon: we also have a roadmap.md on github. It is 99% complete and we could move the spreadsheet to it
19:58:32 <AutomatedTester> ... so do we need a new roadmap or just use github issues?
19:58:35 <AutomatedTester> ack next
19:59:21 <AutomatedTester> sadym: how we prototype things is puppeteer things over and mobile emulation as the main priorities
19:59:30 <AutomatedTester> q?
19:59:35 <jdescottes> q+
19:59:40 <AutomatedTester> ack next
20:00:12 <AutomatedTester> jdescottes: the added value is that it give the priorities from clients but this may not be reality
20:00:31 <AutomatedTester> ... I think the labels on the github would give us the same value
20:01:44 <AutomatedTester> action: create an issue to how to have github as single source of truth
20:04:44 <AutomatedTester> RRSAgent: make minutes
20:04:45 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/15-webdriver-minutes.html AutomatedTester