[wdspec] Update tests for "viewport" argument for "browsingContext.setViewport" to check for scrollbar sizes
Categories
(Remote Protocol :: WebDriver BiDi, task, P2)
Tracking
(firefox126 fixed)
Tracking | Status | |
---|---|---|
firefox126 | --- | fixed |
People
(Reporter: whimboo, Assigned: Sasha)
References
(Blocks 1 open bug)
Details
(Whiteboard: [webdriver:m10], [wptsync upstream])
Attachments
(2 files)
Several Puppeteer P2 tests are encountering failures due to discrepancies in screenshots taken from a modified viewport compared to those produced by Chrome. The underlying issue lies in the fact that we display scrollbars, while Chrome completely disables them. This leads to differences in the default clientWidth and clientHeight. Consequently, when scrollbars are not shown, the dimensions are larger, causing a distinct reflow of elements on the page.
For instance, setting the viewport to 500x500 currently results in 500px in width for pages without a vertical scrollbar, but it becomes 485px when a scrollbar is present. Since we cannot dynamically adjust the viewport size based on the loaded document or scrollbar visibility, it is essential to ensure that the viewport is set to the exact size. Achieving this, however, seems possible only when scrollbars are disabled or overflow scrollbars are visible. It's important to note that the latter scenario may introduce challenges with HIT testing, especially if elements are positioned beneath the scrollbars.
As the attached image shows the 9th box reflows to the next row while it should be visible as last box of the first row.
Reporter | ||
Comment 1•3 months ago
|
||
Emilio, do you know if we have the possibility (eg. a preference) to disable scrollbars completely? Or maybe there is another way to get around the above mentioned problem? Thanks!
Comment 2•3 months ago
|
||
ui.useOverlayScrollbars=1
should make scrollbars not take space, does that help?
Reporter | ||
Comment 3•3 months ago
|
||
It indeed helps here. But I assume that this will trigger issues when action commands try to click on elements that are now behind the scrollbar. If that's the case is there any way to disable scrollbars completely?
Comment 4•3 months ago
|
||
I guess widget.non-native-theme.scrollbar.size.override=0
might do.
Reporter | ||
Comment 5•3 months ago
|
||
That is not working at least on MacOS. And 0
is actually already the default value of this static preference.
Reporter | ||
Comment 6•3 months ago
|
||
While further investigating this issue I noticed that in Puppeteer tests the CSS pseudo variable --webkit-scrollbar
was used to disable the scrollbars in Chrome. This is not cross-browser compatible and needs to be replaced with scrollbar-width
. I will use bug 1878324 for that fix in the Puppeteer tests, and for an early landing on mozilla-central.
Otherwise Chrome also displays scrollbars if necessary which is in sync with our behavior. But we should write some more wdspec tests to verify different scenarios.
Reporter | ||
Comment 7•3 months ago
|
||
Lets update the bug's summary to have it covering the test creation for wdspec.
Reporter | ||
Updated•3 months ago
|
Comment 8•3 months ago
|
||
The severity field is not set for this bug.
:whimboo, could you have a look please?
For more information, please visit BugBot documentation.
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Comment 9•2 months ago
|
||
Comment 10•2 months ago
|
||
Pushed by aborovova@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/99d244bc49eb [wdspec] Update tests for "viewport" argument for "browsingContext.setViewport" to check for scrollbar sizes. r=webdriver-reviewers,whimboo,jdescottes
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/45371 for changes under testing/web-platform/tests
Comment 12•2 months ago
|
||
bugherder |
Upstream PR merged by moz-wptsync-bot
Description
•