[aik099]

Adds tests for click, double-click, right-click and mouse over on elements that are below the viewport. Each test scrolls to the top of the page first, so the element is outside the viewport when the driver method is called.

W3C drivers scroll the element into view for clicks themselves, but drivers that move the mouse to the element first may not. For example, MinkSelenium2Driver on Selenium 3 + Firefox fails with:

MoveTargetOutOfBounds: Move target (640, 1934) is out of bounds of viewport dimensions (1280, 860)

That's fixed in minkphp/MinkSelenium2Driver#389, which waited for a test like this.

Tested locally (macOS, Selenium jars, Brave 155 and Firefox 157):

• https://github.com/minkphp/webdriver-classic-driver on Selenium 4.17: all 4 tests pass
• https://github.com/minkphp/MinkSelenium2Driver on Selenium 3.141.59 with Fixing clicking outside of a viewport issue MinkSelenium2Driver#389: click, double-click and mouse over pass; right-click is skipped there (not supported on Selenium 3.x)
• https://github.com/minkphp/MinkBrowserKitDriver: whole test suite still passes

🤖 Generated with Claude Code

[uuf6429]

I'm wondering if we should add preventDefault()/stopPropagation() everywhere.
Some browsers, like MS Edge show a menu context menu when text is selected via double click, for instance.

[aik099]

@uuf6429, this deserves a separate task/pr with research attached. Test suite doesn't really fail without them, but to avoid any future failing tests due to unexpected event propagation, this could be handy.

[uuf6429]

Just thinking out loud, could it make sense to use pointer events (which also capture touch etc) instead? Or do we maybe specifically want these mouse events?

I guess it's more of a question on the mink side - that touch events should be a different API?

[aik099]

@uuf6429, we'd better create an issue in Mink repo itself for discussing such API.

Some ideas:

• understand underlying driver support for pointer events?
• how are js events triggered (does mouse* event trigger matching pointer* event and vice versa)?
• how do mouse/pointer events behave on desktop/mobile devices?
• what about community-built Mink drivers (Chrome, Playwright, etc.)?

What I try to avoid here is by making the current mouse-api acting as point event API causing a break for desktop users. If we do introduce parallel pointer-api, then could drivers actually handle it without Syn-based magic.