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.