#149 Fix returned value of isTextTypeInput method

See merge request !174

Always preserve test report artifacts

See merge request !179

Name job reports separately

See merge request !180

Print PHP version in CI jobs

See merge request behat-chrome/chrome-mink-driver!183

#155: Disable Chrome build jobs (Chromium, beta etc) where zenika/alpine-chrome does not offer them

#155: Use zenika/alpine-chrome

See merge request !185

#152: Close other windows when resetting session

See merge request !178

#158: Throw exception if setValue() called without boolean value on checkbox

See merge request !192

[minkphp/driver-testsuite#101](https://github.com/minkphp/driver-testsuite/pull/101) has introduced test coverage which expects an exception if we attempt to switch to a window which does not exist. chrome-mink-driver previously tried to handle this by dynamically creating popups with `window.open()`, but we will now throw a DriverException instead.

#158: Remove fallback efforts for missing windows

See merge request !193

Chris Burgess authored Jan 28, 2025 and Chris Burgess committed Jan 28, 2025

PHP 8.4 tests fail due to unresolved indirect deprecations in other packages, that can happen in a separate issue.

```
$ vendor/bin/phpunit --colors=always --log-junit junit.xml
PHPUnit 9.6.22 by Sebastian Bergmann and contributors.
...............................................................  63 / 255 ( 24%)
............................................................... 126 / 255 ( 49%)
............................................................... 189 / 255 ( 74%)
............................................................... 252 / 255 ( 98%)
...                                                             255 / 255 (100%)
Time: 00:36.224, Memory: 14.00 MB
OK (255 tests, 549 assertions)
Remaining indirect deprecation notices (1)
  1x: WebSocket\ConnectionException::__construct(): Implicitly marking parameter $prev as nullable is deprecated, the explicit nullable type must be used instead
    1x in CookieTest::testHttpOnlyCookieIsDeleted from Behat\Mink\Tests\Driver\Basic
```
- https://gitlab.com/behat-chrome/chrome-mink-driver/-/jobs/8964093789

#153: Update PHP versions tested in CI

See merge request !195

#161: Use docker-chrome-headless image, not composer, for GrumPHP and Changelog checks

Composer image would be faster, but it defaults to the latest stable PHP version, better to manage this. Using a docker image feels a bit indirect but will do for now.

#161: Use docker-chrome-headless image, not composer, for...

See merge request !196

Specify minimum supported php version

See merge request !197

Minor developing docs improvements

See merge request !194

Andrew Coulton authored May 09, 2022 and Chris Burgess committed Jan 29, 2025

Previously this was silently skipping out of the waitFor loop,
I don't think that can be right. There's no comment or
information in the code or commit history to indicate why this
was the case - it has been there ever since the very first
commit. Possibly it was originally meant to be a `continue`?

Even if we do encounter this happening, it seems entirely wrong
to allow the calling code to continue without waiting for any
further events or any indication that the thing it was actually
waiting for has happened.

Therefore throw an exception and we can then explore if / when
/ how to deal with it once we know when & why it happens.

Andrew Coulton authored May 10, 2022 and Chris Burgess committed Jan 29, 2025

Setting manual request headers on a Chrome instance seems
somewhat unlikely, but it is exposed by the Mink interface
and implemented by the driver so they do need to be cleaned
up as part of ->reset() if present.

However, if the browser or devtools connection has crashed /
hit a problemn then calling Network.setExtraHttpHeaders can
fail in a way that masks and/or makes it harder to trace the
actual failure.

Therefore, avoid sending this call unless it is actually
required (e.g. some custom headers have been set since the
session started or was last reset).

Andrew Coulton authored May 11, 2022 and Chris Burgess committed Jan 29, 2025

Animation events produce a flood of events on the dev-tools
protocol particularly (in many projects) around the time of
click, page-load etc events. This may be contributing to
backlogging the socket and the driver occasionally missing
a more important page completion etc event.

The rate of animation events is particularly high because
we are also setting a massive animation playback rate so
animations start and stop very quickly. It is therefore
virtually impossible to actually interact with an element
during an animation.

The code *looks* like it is sleeping when animations begin
- this was introduced in b0239834 and "fixed" in 0b8113f4.
However, in practice that fix actually just disabled the
sleep because the parameter from DevTools is actually in
`$data['params']['animation']['source']['duration']` (note
the extra `animation` in the path). So the `if (!empty(`
has always been returning false and the driver has never
actually been running any code in response to these events.

If there was a desire / need to reintroduce sleeping
during animations in future, we'd need to review the units
of the `duration` value, and whether just multiplying that
by 10 is even close to the actual time taken when playing
back at the forced accelerated rate.

Andrew Coulton authored May 11, 2022 and Chris Burgess committed Jan 29, 2025

DevTools has deprecated the old flow of setting overrideCertificateErrors
and then handling an event notification. Instead they are just ignored
upfront.

The driver was migrated to the new flow in 457160a5 in 2018, but this
(now-dead) code was not removed at the time. These events will not have
been arriving since then, but leaves another place in the code where it
looks like the page state might change.

Add gitattributes file; update gitignore

See merge request !199

Fix double loop in session reset.

See merge request !190

Chris Caldwell authored Sep 13, 2024 and Chris Burgess committed Jan 29, 2025

#156

Chris Caldwell authored Sep 27, 2024 and Chris Burgess committed Jan 29, 2025

#156

Chris Caldwell authored Sep 27, 2024 and Chris Burgess committed Jan 29, 2025

#156

Fix broken key methods

See merge request !184

Disable auto retry for PHPUnit jobs in CI

See merge request !201

Ere Maijala authored Jan 07, 2025 and Chris Burgess committed Feb 04, 2025

These changes ensure that calling ChromeDriver::stop() will close all websocket connections. Otherwise a large test project that uses a lot of sessions can run out of open file descriptors due to the TCP connections being left in ESTABLISHED or CLOSE_WAIT state.

Fix closing of websocket connections.

See merge request !189

Reuse chrome url

See merge request !198

Small internal improvements to DevTools protocol connections

See merge request !188

Document a few things

See merge request !177

Revert changes from !188

See merge request !202

#166

#166

Cause Page.frameDetached to set page to ready state

See merge request !209

Respect current window height in getScreenshot()

See merge request !208

Andrew Coulton authored May 09, 2022 and Chris Burgess committed Oct 03, 2025

Previously this was silently skipping out of the waitFor loop,
I don't think that can be right. There's no comment or
information in the code or commit history to indicate why this
was the case - it has been there ever since the very first
commit. Possibly it was originally meant to be a `continue`?

Even if we do encounter this happening, it seems entirely wrong
to allow the calling code to continue without waiting for any
further events or any indication that the thing it was actually
waiting for has happened.

Therefore throw an exception and we can then explore if / when
/ how to deal with it once we know when & why it happens.

Andrew Coulton authored May 11, 2022 and Chris Burgess committed Oct 03, 2025

Animation events produce a flood of events on the dev-tools
protocol particularly (in many projects) around the time of
click, page-load etc events. This may be contributing to
backlogging the socket and the driver occasionally missing
a more important page completion etc event.

The rate of animation events is particularly high because
we are also setting a massive animation playback rate so
animations start and stop very quickly. It is therefore
virtually impossible to actually interact with an element
during an animation.

The code *looks* like it is sleeping when animations begin
- this was introduced in b0239834 and "fixed" in 0b8113f4.
However, in practice that fix actually just disabled the
sleep because the parameter from DevTools is actually in
`$data['params']['animation']['source']['duration']` (note
the extra `animation` in the path). So the `if (!empty(`
has always been returning false and the driver has never
actually been running any code in response to these events.

If there was a desire / need to reintroduce sleeping
during animations in future, we'd need to review the units
of the `duration` value, and whether just multiplying that
by 10 is even close to the actual time taken when playing
back at the forced accelerated rate.

Andrew Coulton authored May 11, 2022 and Chris Burgess committed Oct 03, 2025

DevTools has deprecated the old flow of setting overrideCertificateErrors
and then handling an event notification. Instead they are just ignored
upfront.

The driver was migrated to the new flow in 457160a5 in 2018, but this
(now-dead) code was not removed at the time. These events will not have
been arriving since then, but leaves another place in the code where it
looks like the page state might change.

Small internal improvements to DevTools protocol connections (v2)

See merge request !203

Andrew Coulton authored May 10, 2022 and Chris Burgess committed Oct 03, 2025

Setting manual request headers on a Chrome instance seems
somewhat unlikely, but it is exposed by the Mink interface
and implemented by the driver so they do need to be cleaned
up as part of ->reset() if present.

However, if the browser or devtools connection has crashed /
hit a problemn then calling Network.setExtraHttpHeaders can
fail in a way that masks and/or makes it harder to trace the
actual failure.

Therefore, avoid sending this call unless it is actually
required (e.g. some custom headers have been set since the
session started or was last reset).

Andrew Coulton authored Feb 06, 2025 and Chris Burgess committed Oct 03, 2025

Chrome closes windows asynchronously, which was causing tests to
fail when checking that `->reset()` correctly closes non-main
windows.

This commit uses the JSON API to ensure that the windows have
actually closed before the `->reset()` call returns.

In my testing, even making one call to `/json/list` is long enough
to allow the operation to complete. However I have added a retry
loop with a short timeout to cater for slow machines / transient
resource pressure.

Andrew Coulton authored Feb 06, 2025 and Chris Burgess committed Oct 03, 2025

`ChromeDriver::close()` starts by calling `->reset()` which
internally closes all non-main windows. The subsequent attempt
to enumerate windows and close all but the first is therefore
redundant.

It is possible this was historically helping with the timing
issue of windows closing asynchronously after reset(), however
this has now been resolved and the windows are guaranteed to
be closed by the time reset() returns.

Only reset request headers after scenario if they were set

See merge request !204

Add Renovate configuration (#153, #161)

See merge request !211

chore: Configure Renovate

See merge request !212

Renovate configuration

See merge request !213

Composer changes in CI

See merge request !217

Remove composer-lock-diff - no lockfile!

See merge request !218

chore(config): migrate renovate config

See merge request !219

#163: Release 2.10.0

See merge request !220