ChromeDriver 110.0.5481.77 has been released

[Vladimir Nechaev]

Hello ChromeDriver users,

We are happy to announce that ChromeDriver version 110.0.5481.77 has been released, and is now available at the ChromeDriver Downloads site. This version of ChromeDriver is intended for users of the current Stable release of Chrome version 110.

Changes in this version of ChromeDriver include:

• Resolved issue 4193: Failed to start new session on Android 13 [Pri-]

• Resolved issue 4272: WebSocket should treat code=0 as an indication of FIN [Pri-]

• Resolved issue 4276: Fix connectivity issues in ChromeDriver [Pri-]

• Resolved issue 4295: ChromeDriver with `"webSocketUrl": true` is racy [Pri-]

• Resolved issue 4297: ChromeDriver Bidi serializes incorrectly [Pri-]

Please see the release notes 110.0.5481.77 for a more complete list of changes included in this release.

Thanks for your continued support of ChromeDriver, and please let us know if you have any questions.

Sincerely,

The ChromeDriver Team

[mike work]

Hi,

It still runs only in headless mode.

Is there any plan to support debug run with chrome UI like was until ChromeDriver  108.0.5359.7100?

Really hope so, since then we use Firefox driver: geckodriver to debug selenium automation tests.

Thanks,

Mike. 

[Jodi Chalupa]

Hello, 

We're having an issue with both versions of 110.  Specifically this pref for file download location is not working

prefs.put("download.default_directory", "/directory/path");

[Sean Abraham]

I'm also having the problem that Jodi mentions, and it's in code that was working fine before this version of ChromeDriver.

Specifically, the download.default_directory setting isn't working in headless mode. Downloads aren't being saved to that specified directory anymore.

However, download.default_directory does still work for me when I don't enable setHeadless.

[Laura Buržinskaitė]

Hello, I am also experiencing this issue, when download location is not working in headless mode with 110 chromedriver. Files are downloaded to the root dir instead of the specified dir. Works non-headless though. Using wdio.

[Andrius Vetrenka]

The download.default_directory setting isn't working in headless mode, Downloads are saved to the root folders ignoring download.default_directory settings

On Thursday, February 9, 2023 at 6:03:06 AM UTC+2 Sean Abraham wrote:

[Dawid Bednarek]

Same problem with download directory here on macOS arm m1 Monterey 12.0.1. The problem occurs both with and without the headless option. On Windows 10 the problem does not occur.

[Erikas Kaleininkas]

Same issue here. File is downloaded to the root directory

[Sean Abraham]

Jodi logged a ticket here for the headless download directory issue: https://crbug.com/chromedriver/4356

Though it's hard to tell if the bug is in chromedriver or in chromium itself (i.e. maybe this belongs in the Internals>Headless component?)

[Pawel Winarski]

Attaching logs, maybe it will be helpful. 

Note that  downloadProgress  ends with  "state": "canceled"  in headless mode, despite receivedBytes  =  totalBytes.  

In non-headless mode I am getting "state": " completed " and all works fine


[1675952584.077][DEBUG]: DevTools WebSocket Event: Page.downloadWillBegin (session_id=351F670B3A91D14085DDFAAAE86729EB) 8306530BAD6429B331E577EBA44C5972 {
   "frameId": "8306530BAD6429B331E577EBA44C5972",
   "guid": "bd39f1fb-1fc1-4593-af03-2367f283d9a7",
   "suggestedFilename": "Trips-2023-02-09-14-23-05.xlsx",
   "url": "blob:https://aaaaaaaa.org/011e7782-5d5a-4252-8b3f-83ac3a8ae706"
}
[1675952584.079][DEBUG]: DevTools WebSocket Event: Page.downloadProgress (session_id=351F670B3A91D14085DDFAAAE86729EB) 8306530BAD6429B331E577EBA44C5972 {
   "guid": "bd39f1fb-1fc1-4593-af03-2367f283d9a7",
   "receivedBytes": 0,
   "state": "inProgress",
   "totalBytes": 7462
}
[1675952584.079][DEBUG]: DevTools WebSocket Event: Page.downloadProgress (session_id=351F670B3A91D14085DDFAAAE86729EB) 8306530BAD6429B331E577EBA44C5972 {
   "guid": "bd39f1fb-1fc1-4593-af03-2367f283d9a7",
   "receivedBytes": 7462,
   "state": "inProgress",
   "totalBytes": 7462
}

[1675952584.106][DEBUG]: DevTools WebSocket Event: Page.downloadProgress (session_id=351F670B3A91D14085DDFAAAE86729EB) 8306530BAD6429B331E577EBA44C5972 {
   "guid": "bd39f1fb-1fc1-4593-af03-2367f283d9a7",
   "receivedBytes": 0,
   "state": "canceled",
   "totalBytes": 7462
}

[M S]

I also have error ->  "unknown error: DevToolsActivePort file doesn't exist while trying to initiate Chrome Browser", when i try to run my tests under Chrome (110.0.5481.78). It's pretty big issue for me, because it's hard to debug script in headless mode. The same with default download directory. When can we expect fix for these bugs?

[C Smith]

We are seeing a similar issue with the Downloads folder.  With debugging enabled we get these messages back when running in headless mode:

[0209/131024.392:VERBOSE1:webrtc_internals.cc(123)] Could not get the download directory.
[0209/131024.397:VERBOSE1:media_stream_manager.cc(1339)] MSM::InitializeMaybeAsync([this=000031C400034D80])
[0209/131024.407:VERBOSE1:media_stream_manager.cc(1339)] MDM::MediaDevicesManager()
[0209/131024.413:VERBOSE1:media_stream_manager.cc(1339)] MSM::MediaStreamManager([this=000031C400034D80]))
[0209/131024.416:VERBOSE1:first_party_sets_handler_impl.cc(264)] Empty path. Failed initializing First-Party Sets database.

[Иван Тургенев]

I use Selenium with OS X and Debian and using

--headless=new 

instead of the 

--headless 

did the trick for me.

Can reference to https://bugs.chromium.org/p/chromium/issues/detail?id=1409043&q=component%3AInternals%3EHeadless&can=2&sort=-modified and https://chromium-review.googlesource.com/c/chromium/src/+/4000223

четверг, 9 февраля 2023 г. в 21:35:54 UTC+3, C Smith:

[Dmitry Belykh]

Windows 10 I have tried  

--headless=new 

Downloading is working, but the setting "--window-size=1920,1080" is not. 

So, locally instead of 1920x1080 I have a size of 1904x890 on the local machine and  1028x653 on the Azure cloud windows agents.

It was OK on the previous Chrome versions and on old headless mode. 

вторник, 14 февраля 2023 г. в 18:26:25 UTC+1, Иван Тургенев:

[Jodi Chalupa]

guess this was expected:  https://stackoverflow.com/questions/75367068/deprecationwarning-headless-property-is-deprecated-instead-use-add-argument

adding "--headless=new" worked for me too.  Thanks all!

[Laura Buržinskaitė]

With the new flag --headless=new download.default_directory is working on Mac. But "--window-size=1920,1080" is not. It is setting max size width: 1440, height: 797, even when I specify bigger sizes.

[Smitha Bhandary]

Any solution for this? I am also unable to start session on macOS arm m1 Monterey 12.0.1

[Gerard Kmieć]

Same issue. I am using  "--headless=new" and "options.AddUserProfilePreference("download.default_directory", Environment.GetFolderPath(Environment.SpecialFolder.UserProfile));"

I have multisystem tests which runs both on Linux and Windows, and on Windows everything is ok, on Linux file is not downloaded to UserProfile location.

Everything was working on chromedriver 109

[Eric kuen]

please im trying to install chrome with this driver version  87.0.4280.88.. where can i find the installer please