Extend browsingContext.setViewport with scrollbarType

[sadym-chromium]

Closed in favor of #1064

Addressing yet another part of #772.

Related CSS PR: w3c/csswg-drafts#13240

---

Preview | Diff

[whimboo]

Thanks Maksim. I had a quick skim through and have two topics from my side.

[lutien]

I recall that there were concerns about issues with setting some scrollbar types on certain platforms (like, e.g., it's fine for desktop but not for mobile). So maybe it would be better to have a separate command so it's easier to indicate if some option is not supported?

[sadym-chromium]

I recall that there were concerns about issues with setting some scrollbar types on certain platforms (like, e.g., it's fine for desktop but not for mobile). So maybe it would be better to have a separate command so it's easier to indicate if some option is not supported?

The method allows for setting only a single parameter "scrollbarType", so the client can send 2 commands if they want to.

[whimboo]

Looks fine to me, but can you please check if this to introduce override will work across all platforms? Like setting classic for mobile might not work, or? There is a still open action item for myself as I just noticed, which I haven't had the time for to check.

[jgraham]

I don't quite see why the change to set scrollbars needs to be in CSS Overflow, it's extremely webdriver-specific. I suggest inlining that here instead and just linking to the definitions of classic and overlay scrollbars.

I also think that helps with Henrik's feedback; because we know we have a catch all "if you aren't going to be able to do this operation abort" at the start of the setViewport steps it's easier to justify the assumption that the algorithm can be treated as infallible. However I'd still suggest it's better to make it fallible and just know that when we call it from that command it's not going to fail.

[sadym-chromium]

I don't quite see why the change to set scrollbars needs to be in CSS Overflow, it's extremely webdriver-specific. I suggest inlining that here instead and just linking to the definitions of classic and overlay scrollbars.

Moved to the WebDriver BiDi spec.

I also think that helps with Henrik's feedback; because we know we have a catch all "if you aren't going to be able to do this operation abort" at the start of the setViewport steps it's easier to justify the assumption that the algorithm can be treated as infallible. However I'd still suggest it's better to make it fallible and just know that when we call it from that command it's not going to fail.

I mentioned it in the first step of the "browsingContext.setViewport" command:

If the implementation is unable to adjust the layout viewport parameters or scrollbar type with the given command parameters for any reason, return error with error code unsupported operation.

[whimboo]

Looks fine to me. Thank you @sadym-chromium. Maybe lets have @jgraham another look as well before we merge the PR.

[sadym-chromium]

@jgraham WDYT?

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Scrollbar emulation.

The full IRC log of that discussion

<AutomatedTester> topic: Scrollbar emulation
<AutomatedTester> github: https://github.com//pull/1050
<tidoust> sadym: Scrollbar types. We want to allow for switching between classic and overlay scrollbars to emulate mobile devices.
<tidoust> ... With yesterday's discussion in mind, it should perhaps be a dedicated command.
<AutomatedTester> q?
<tidoust> ... I believe the decision here would be: would people support setViewport together with scrollbarType, or should they be separate?
<sasha> q+
<AutomatedTester> ack next
<tidoust> sasha: Setting viewport may not be only about mobile emulation. You would not need to set the scrollbar type in such cases.
<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.
<sadym> q+
<tidoust> ... Device pixel ratio would also be changing the screen settings rather than the viewport.
<orkon> q+ desktop systems can have different scrollbar types AFAIK
<tidoust> ... I would want setViewport to only change the viewport and have other settings somewhere else.
<AutomatedTester> q?
<tidoust> q+ orkon to say that desktop systems can have different scrollbar types AFAIK
<AutomatedTester> ack next
<tidoust> sadym: I don't think it belongs to emulation. We're switching the scrollbar type, not emulating some of them.
<tidoust> ... I'm going to add a dedicated comment.
<AutomatedTester> q?
<AutomatedTester> s/comment/command
<tidoust> s/comment/command/
<AutomatedTester> ack next
<Zakim> orkon, you wanted to say that desktop systems can have different scrollbar types AFAIK
<tidoust> orkon: Scrollbar types can be relevant for desktop. I think on Safari, you can change that in the settings in particular.
<AutomatedTester> q?
<whimboo> q+
<AutomatedTester> ack next
<jdescottes> s/Safari/macos/
<tidoust> whimboo: How should we behave by default? The resulting viewport may be different and a test could fail as a result.
<AutomatedTester> q?
<sadym> q+
<AutomatedTester> ack next
<jgraham> q+
<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
<AutomatedTester> ack next
<tidoust> jgraham: I think the default should be whatever the browser does by default.
<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.
<tidoust> ... We shouldn't change anything by default just because we start a WebDriver BiDi session.
<AutomatedTester> q?
<sadym> q+
<AutomatedTester> ack next
<tidoust> sadym: The consensus is to move it to a dedicated command, and to let browsers use their own default.

[sadym-chromium]

Deprecated by #1064

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Scrollbar emulation.

The full IRC log of that discussion

<AutomatedTester> topic: Scrollbar emulation
<AutomatedTester> github: https://github.com//pull/1050
<AutomatedTester> sadym: this is what we discussed 3 weeks ago about scrollbar emulation
<jgraham> RRSAgent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2026/02/11-webdriver-minutes.html jgraham
<AutomatedTester> ... I think we have consensus. What I wanted to bring in this PR to be more generic
<AutomatedTester> ... <discusses there a number of different items to store data>
<jgraham> q+
<AutomatedTester> ... we currently have a singleton for the remote end but not for the session
<AutomatedTester> ack next
<AutomatedTester> jgraham: I only briefly looked in the PR but it looked like a good way to store data for the we are setting up in the session
<AutomatedTester> ... and this will lead to being more consistent with how we look up data
<AutomatedTester> sadym: this is a blocker for all emulation that we are going to specify. I would like to reuse this as I build out the other emulation. Please can people unblock me by reviewing this PR
<AutomatedTester> q?
<whimboo> q+
<AutomatedTester> ack next
<AutomatedTester> whimboo: I am on PTO over the next week. If others can help review. I looked and it looked ok for now
<AutomatedTester> jgraham: I think it would be good to have the config item split out into a new PR and then have a PR for emulation that then uses it
<AutomatedTester> sadym: this would be odd and it would need an example of how to use it so that's why its in that PR
<AutomatedTester> jgraham: it's fine to be in the PR but ideal case would be PR for infra and a PR for emulation to see it being used but I can do it in 1 PR
<AutomatedTester> q?