Q about auto scroll-to-top and hiding of scrollbars

[benurb]

Hello there! 👋

while working with WebdriverCSS I stumbled upon two problems, which I'm unsure how they should be handled correctly.

1. WebdriverCSS scrolls up/left to x 0, y 0 before it takes any screenshots. But some page elements are dependent on the scroll position (e.g. a scroll spy on a navigation menu).
2. Also before taking any screenshots the scrollbars are removed, which changes the width of the document and may lead to layout recalculations. Especially if they are done in JavaScript, which is unfortunately still needed in some cases, they might not be finished when the screenshot creation starts.

Any opinions how these problems should be handled?

Here are mine:

1. WebdriverCSS should not scroll up. The scrolling via transform should start at initialScrollPositionY, initialScrollPositionX and end at -(pageHeight - initialScrollPositionY), -(pageWidth - initialScrollPositionX). This way a screenshot of the whole page can be made without actually scrolling. If that's the way to go I can of course create a pull request for this one.
2. I added the following code block to problematic tests to hide the scrollbars from the beginning leaving more time to the javascript to update the layout:

.execute(function () {
  document.body.style.overflow = "hidden";
})

Apart from that I have no idea how this one could probably be fixed. Help! 😄

Best regards,
Ben

[christian-bromann]

Hi Ben,

well the idea behind the scrolling is to ensure that WebdriverCSS takes a screenshot of the whole page. As you've pointed out this can cause problems if you use some kind of spy that handles page elements according to their scroll position. I have no idea either how to handle that. I hope that one day all browser driver will capture screenshot of the whole browser but I don't see that coming soon as some them have specific routines to increase performance once an elements get out of the viewport.

Your second point is tricky too. We remove scrollbars to avoid having regressions because of them. Usually the time until the screenshot is taken is sufficient for the browser to repaint itself but if JavaScript is involved this can take longer. Not sure how to fix this either. It is hard to figure out when a browser has finished with rendering.

At the end I might be a good idea to consider using additional browser plugins to get more control over the browser. Their APIs have way more opportunities to take screenshots reliable. But it will take effort to come up with a plugin for each browser and then we also have mobile devices to cover.

[benurb]

Hey Christian,

about the first problem (scroll to top before taking screenshots): Should I create a pull request that uses positive transform values instead of actually scrolling up or is this not needed?

Ben

[DennisHartevelt]

At the moment we encounter the same problem Ben describes. Sometimes the browser isn't finished repainting itself after the scrollbar are deleted by webdrivercss. I was wondering if a fix or a workaround is already available?

[archive64]

I've been having a similar problem. The scrollbars affect the width of the content area in some screenshots, but not every screenshot.

I've had some luck with running this code before the comparison:

// workaround for flaky screenshots from scrollbars
var styleElement = document.createElement('style');
document.head.appendChild(styleElement);
styleElement.sheet.insertRule('::-webkit-scrollbar { display: none; }');