Headless=new cannot use a WindowSize greater than the Windows User's screen resolution.

6,409 views
Skip to first unread message

C Smith

unread,
Feb 12, 2023, 2:02:38 PM2/12/23
to ChromeDriver Users
I'm running a test process using Cucumber, Selenium and Capybara for the screenshots.

I'm passing these arguments to the browser instance (removing the =new in the --headless argument to get the Old Headless Mode to trigger.

  options.add_argument('--headless=new')
  options.add_argument('--start-maximized')
  options.add_argument('--disable-popup-blocking')
  options.add_argument('--disable-extensions')
  options.add_argument('--window-size=1960,1080')
  options.add_argument('--disable-features=VizDisplayCompositor')
   options.add_argument('--user-data-dir=C:\FourthTest')

To demonstrate this, when I remote desktop to my test running system, I'm forcing it to use 800x600 resolution.  Headless mode, as far as I can tell, should not care about my screen resolution.  The old headless mode does not care about my resolution, and as you can tell from the OldHeadless Screenshot PNG I'm attaching here, the browser window is using 1960 by 1080 pixels.  The NewHeadless Screenshot PNG is at 804x487 pixels, which appears to be an artifact of the browser taking the Windows Taskbar into account for the browser window size(?).

If I set my remote desktop window to a larger resolution than 1960x1080, then everything works as expected for both modes.  However, we have a CI process where regression tests are run automatically by Jenkins agents on Windows VMs created only to have these tests run against them. These agents are Windows Services and they don't have a real windows session running where you can adjust the screen resolution.

screenshot_OldHeadlessMode.png
screenshot_NewHeadlessMode.png

Mathias Bynens

unread,
Feb 13, 2023, 1:13:19 AM2/13/23
to C Smith, ChromeDriver Users, Peter Kvitek
--
You received this message because you are subscribed to the Google Groups "ChromeDriver Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromedriver-us...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chromedriver-users/c6d6f182-19fd-4288-a57a-78c58d5c2d29n%40googlegroups.com.

Oli Gee

unread,
Feb 14, 2023, 2:21:44 AM2/14/23
to ChromeDriver Users
We had some similar issues with an edge update a while ago.
Could you try to change the user the jenkins agent is startet with, from system to a "normal" user?

Peter Kvitek

unread,
Feb 14, 2023, 8:36:50 PM2/14/23
to Mathias Bynens, C Smith, ChromeDriver Users
Yup, confirmed: https://crbug.com/1416398 

Turns out Windows clamps newly created windows' size to the active desktop work area. New Headless Chrome was using the platform window size disregarding --window-size setting if it was larger than the active display work area.

This CL deals with this issue by tracking the expected window size on Windows and tricking upper layers to believe that it's what it was set to. This is the approach we took with platform window visibility and activation states, so it is not something new. This fixed the problem for me -- I was able to set --window-size to the value much larger than the display area and observe the expected content sizes via remote debugging.

Note that we may have a similar problem on the Mac, I'll investigate tomorrow. Linux is not subject to this problem because it does not use any platform windows, they are completely  abstracted by Ozone/Headless.

Best,
/Peter

C Smith

unread,
Feb 15, 2023, 9:25:46 AM2/15/23
to ChromeDriver Users

Thanks Peter.  I'll star that bug report to keep an eye on what's happening. 

Johan Botha

unread,
Feb 18, 2023, 5:08:03 PM2/18/23
to ChromeDriver Users
This is causing issues when running headless=new inside a windows service. It is defaulting to 800x600 and nothing changes it. 

Hopefully this will fix it, but not sure, since on the same machine I can run it from Visual Studio without issues. 

I also think 800x600 might be a less than ideal (somewhat outdated) default, it might be nice to go with something bigger, perhaps 1920x1080.

This became a bigger issue, dropping production, as our code was using the old "headless" tag and that stopped working on 110, and we had to use "headless=new", but that had this issue.

Trying to role back Chrome was a nightmare as one can't find the installs or binaries. I was lucky to have a VM around that was powered down for the last few days and still had 109 (I dropped offline before starting it). It is really not ok for Chrome not to be able to roll back. 

On Tuesday, February 14, 2023 at 8:36:50 PM UTC-5 Peter Kvitek wrote:

Ray Amos

unread,
Feb 19, 2023, 2:36:18 AM2/19/23
to ChromeDriver Users
We're in the same boat. This has absolutely killed us this week. We have tests that download files, so fail if we use the old headless driver. We have tests that have elements that are not showing as "Displayed" due to the window size issue, so are failing with the new headless driver. We cannot roll back Chrome either, so are dead in the water as far as automated UI testing goes until one or both of these is fixed.

C Smith

unread,
Feb 19, 2023, 5:56:29 AM2/19/23
to ChromeDriver Users
You can get a stable Chromium version 109 and its chromedriver using the instructions found here on downloading old versions. 
https://www.chromium.org/getting-involved/download-chromium/

You can just unzip the chromium files into a folder and the use Selenium's option for the binary to point at the chrome.exe file in that folder, if you are using Selenium.

Joshua Mead

unread,
Feb 20, 2023, 9:19:21 AM2/20/23
to ChromeDriver Users
I also have this issue. I see the fix has been merged, any ideas as to when the build will come out containing this fix?

Cheers :)

Andrew Kibler

unread,
Feb 23, 2023, 8:02:30 PM2/23/23
to ChromeDriver Users
Would love a hint on how you are getting this to work, even with old headless mode. In an RD session and from the command line I'm running chrome 112.0.5615.0
No screenshots are saved at all when using headless=new, chrome appears to not load.
When using this command line
"C:\ChromePortableDev_v112\chrome-win\chrome.exe" --headless=old --force-device-scale-factor=1 --start-maximized --disable-extensions --disable-features=VizDisplayCompositor --timeout=5000 --window-size="1280,720" --screenshot="screen.png" --user-data-dir="C:\ChromePortableDev_v112\chrome-win_profile" "URL_HERE"

The screenshot is saved, however it's always 800x600

Fabio Fidanza

unread,
Apr 5, 2023, 12:39:33 PM4/5/23
to ChromeDriver Users
Same here, it broke our system completely, and it doesn't look fixed on Chromium 111

Abdullah Ibne Alam Shohag

unread,
Apr 5, 2023, 11:56:49 PM4/5/23
to ChromeDriver Users
I've tried with Chromium Version: 114.0.5698.0 and it worked (from Google Chrome it's always 800x600).

Downloaded (Chromium 64-bit zip) from https://chromium.woolyss.com/download/ and configured the path variable then took screenshot of 1920x1080 successfully.

FabianT17 (FabianT17)

unread,
Jul 11, 2023, 12:54:11 PM7/11/23
to ChromeDriver Users
Hello i started using "headless=new" instead of "headless" but now when i use "save_screenshot" method the resolution of the screenshot is higher than width and height of the webpage.

Any news of resolution ?
Reply all
Reply to author
Forward
0 new messages