search

w3c / webdriver-bidi

Bidirectional WebDriver protocol for browser automation
https://w3c.github.io/webdriver-bidi/
336 stars 35 forks source link

Add an option to the "browsing.setViewport" command to define a type of scrollbar shown #692

Open lutien opened 3 months ago

lutien commented 3 months ago

At the moment, the spec is not very clear on what is correct behavior when updating the viewport in case there is scrollbar, if we should update the inner window (which means that the area available for the document will be smaller than the requested) or we update the visual viewport, but then we might have problems if certain elements appear or disappear and influence the presence of scrollbar and change the dimensions of the viewport. One possible option could be to have a flag to force an overlay scrollbar, the way it works on mobile. In that case, the scrollbar will not take up the space of the viewport and make the behavior more predictable.

Note: at the moment, Chrome and Firefox both set the requested dimensions to an inner window (window.innerWidth and window.innerHeight), which includes the scrollbar.

Update: see the comments below, the first question if we should update the inner window with the viewport argument is resolved. The answer is yes, it probably it's enough that the spec says that we should update the layout viewport.

The remaining question is around having the argument/capability to control the type of scrollbar shown (overlay or classic). The title of the issue is also updated to reflect what still has to be discussed.

whimboo commented 3 months ago

CC @OrKoN, @sadym-chromium for feedback.

Note that when eg a new element gets added and one or both scrollbars appear a reflow can happen and affect the rendering of content. This can easily be seen with grid layouts.

OrKoN commented 3 months ago

As far as I see window.innerWidth and window.innerHeight reflect the layout viewport dimensions so it sounds like current implementations are correct and match the spec. And the scrollbar might be inside the layout viewport/the scrollable area, thus, affecting the layout.

jgraham commented 3 months ago

I think our conclusion here is that the spec and implementations match, but they don't match what people probably want for emulating mobile, which is to force overlay scrollbars, thereby sidestepping this problem. So I think the solution here is probably to have a field in the setViewport command that forces the viewport to use some kind of zero-width ("overlay") scrollbars (obviously with the possibility to return an error if you don't actually support that).

OrKoN commented 3 months ago

@jgraham I would not say it is exclusively for mobile device emulation because it is also useful for media query testing on desktop. In that case, I think it is useful to see if the scrollbar would affect the layout. Especially, given that on some platform overlay scrollbars are on the default (I think Mac? probably also browser specific). I agree that we probably need something to configure the scrollbars but I wonder if it should be a capability, or a separate method, or a flag on setViewport as you suggest. Perhaps scrollbar-width: none can be used as a workaround until something like this is supported?

OrKoN commented 3 months ago

It looks like the following issue is related: https://github.com/w3c/webdriver-bidi/issues/592

lutien commented 3 months ago

Since, as James said, the implementation and the spec probably match. The remaining question is around having the argument/capability to control the type of scrollbar shown (overlay or classic), so I'm going to update the title of this issue and the first comment to make it more clear what we still have to discuss.

whimboo commented 3 months ago

It sounds like that we only want to have it for browsingContext.setViewport but actually scrollbars will also be visible for the default viewport when there is a lot of content exceeding the visual viewport.

So maybe we should define a capability then?

OrKoN commented 2 months ago

I have done additional testing in Chrome and if you currently set the viewport and it causes scrollbars to be shown they are included within the specified (via the protocol) viewport dimensions. It sounds to me that this corresponds to the specification but I wonder if we can improve the definition of what the viewport is and how scrollbars are treated (perhaps via non-normative note?). Re-reading https://drafts.csswg.org/cssom-view/#layout-viewport again I had doubts again if the layout viewport is the right term for what is actually happening.