Question: Wrong keycode expected when using shift modifier in EventsTest::testKeybordEvents?

[robertfausk]

When I send "r" to the browser then keycode 114 is used but when I send r and modifier shift to browser then keycode 82 is used.
I encounter a problem because test case always expects keycode 114.

---

Assertion:

driver-testsuite/tests/Js/EventsTest.php

Lines 104 to 105 in d208035

	$input2->keyPress('r', $modifier);
	$this->assertEquals('key pressed:114 / '.$eventProperties, $event->getText());

Provider:

driver-testsuite/tests/Js/EventsTest.php

Line 117 in d208035

'ctrl' => array('ctrl', '0 / 1 / 0 / 1'),

Pressed r:

Pressed shift+r:

[aik099]

Why test suite doesn't fail currently, when automatic testing is performed on Travis CI?

[robertfausk]

This is exactly what I am also wondering about :D

[aik099]

If you're using Selenium you can actually run that specific test only and through real time debugging (e.g. xdebug) you can pause exactly at the moment after key is pressed to see what's happening.

The test really should be working as if real user is pressing these keys. It's highly unlikely, that keydown/keypress and similar methods in the driver are working incorrectly for so many years and nobody have noticed anything.

Maybe when you press Shift+r it's detected as 2 key presses Shift and r.

[andrewnicols]

I'm also seeing this with my new W3C Driver. This is definitely a bug in this testsuite.

I suspect that the reason that this has not been picked up earlier is that the Selenium2 Drvier is using Syn.js to call:

syn.trigger({{ELEMENT}}, "keypress", $options);

However, syn.trigger is not a part of the public API for Syn, and it literally takes what you give it. It does not convert take the lowercase r key, and apply the shift modifier to it.

If you try this in a browser, you'll see that shift+r gives you a keycode of 82 and the Shift modifier. The same browser shows "shift+r" as having a keycode of 114 (lowercase r) when run with this testsuite, or even just calling syn.trigger directly.

We should replicate the user-browser behaviour within these tests.

This is a bug both in these tests, and also within the Drivers which consume them.