Key::TAB / postValue vs. Chrome 53

[lifeofguenter]

It seems that with recent Chrome (v53) Key::TAB as used in here: https://github.com/minkphp/MinkSelenium2Driver/blob/master/src/Selenium2Driver.php#L681 will actually cause the character \t to be added into the input-box, instead of "hitting the tab key".

I can not reproduce it on a normal workstation setup (e.g. real desktop), but it does not work on a headless chrome setup (Ubuntu 15.10 / selenium-server-standalone-2.53.1.jar):

$ google-chrome-stable --version
Google Chrome 53.0.2785.92

$ chromedriver --version
ChromeDriver 2.23.409687 (c46e862757edc04c06b1bd88724d15a5807b84d1)

Can be reproduced (headless-browser) with the following snippet:

<?php

ini_set('display_errors', true);
error_reporting(E_ALL);

require 'vendor/autoload.php';

$driver = new \Behat\Mink\Driver\Selenium2Driver('chrome');
$session = new \Behat\Mink\Session($driver);

$session->start();

$session->visit('http://localhost/admin/login');
sleep(2);
$session->getPage()->fillField('email', '[email protected]');
$session->getPage()->fillField('password', 'abcdef');
$session->getPage()->pressButton('login');

selenium-server is started like this:

screen -S selenium -d -m sh -c "DBUS_SESSION_BUS_ADDRESS=/dev/null xvfb-run -s '-screen 0 1024x768x24' -a java -jar /opt/selenium-server/selenium-server-standalone.jar > /home/bamboo/selenium.stdout.log 2> /home/bamboo/selenium.stderr.log"

$ java -version
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

Swapping out the browser from chrome to firefox (version 46.0.1) works, as well as removing that Key::TAB from the code above (however not sure if it is the right fix, as obviously it should be working?).

[aik099]

1. maybe this is bug in Selenium, that changes in Chrome (in way how TAB is handled) are not handled properly
2. the TAB is sent to trigger onchange JS event

[lifeofguenter]

Is this maybe related to: instaclick/php-webdriver#70 ?

[adridev]

Facing the same issue here.

Google Chrome 53.0.2785.92

ChromeDriver 2.23.409687 (c46e862757edc04c06b1bd88724d15a5807b84d1)

Selenium server 2.53.1

[fonsecas72]

Did anyone found or confirmed anything?

[aik099]

Me nope. Probably somebody needs to post an issue on Chrome Driver issue tracker (with a link to it posted back here).

[fonsecas72]

ok, just for others to see, if I'm not mistaken, a workaround for findField could be something like this:

$xpath = $this->getSession()->getSelectorsHandler()->selectorToXpath('named', [
    'field',
    $locator
]);
$elementName = strtolower($this->getSession()->getDriver()->getTagName($xpath));
if ($elementName === 'input' || $elementName === 'textarea') {
    $element = $this->mink->getSession()->getDriver()->getWebDriverSession()->element('xpath', $xpath);
    $existingValueLength = strlen($element->attribute('value'));
    $value = str_repeat(Key::BACKSPACE.Key::DELETE, $existingValueLength).$value;
    $element->postValue(['value' => [$value]]);
} else {
    $this->findField($locator)->setValue($value);
}

[aik099]

#243 (comment)

@fonsecas72 , you've just removed TAB if I'm reading this correctly. That is one of possible solutions, but then onchange event won't be fired in JavaScript when value is changed.

[fonsecas72]

yup, users should be aware of the downside when using it. I'd suggest to move it to a special method or something :)

@aik099 if you have a cleaner solution please let me know.

[adridev]

for me, the workaround was to remove the Key::TAB from the end of the line in Selenium2Driver.php:662.

About the "change" event, I don't know if is correct to fire this event automatically when an input is filled. I think could be more natural to have to explicitly hit the enter or leave the field to fire this event.

[aik099]

That change event firing also created problems for testing stuff, like jQueryUI.Autocomplete, because immediately after value change the dropdown with completions was hidden.

@stof , I know this might be a BC break, but maybe for inputs with free text entry (not checkbox/radio button/select) we can stop firing change JS event. If agreed, then we need a way to stop firing change event for other drivers as well.

[lifeofguenter]

I think first we need to figure out if this is a BC break intended by chromedriver/chrome, or if it is actually a bug.

[doriancmore]

How about this? doriancmore@e2710a2

[adridev]

I'm making the same as a workaround but I not sure if is there the correct place for calling to excuteScript.

Probably is more natural to call the blur method after calling to setValue within the step definition. For example:

In \Behat\Mink\Element\TraversableElement:fillField

`
public function fillField($locator, $value)
{

//...

$field->setValue($value);
$field->blur();

}
`

[doriancmore]

The idea is to fix the issue without otherwise altering functionality.

I wouldn't combine a bugfix with a change like that.

[adridev]

It's true, you are right.

[aik099]

How about this? doriancmore@e2710a2

@adorin , the $this->executeScript("document.activeElement && document.activeElement.blur()"); can be replaced with $this->blur($xpath);. As long as tests pass that would solve this problem.

@adridev , I've suggested an update to @adorin solution according to your suggestion.

[kwoxer]

Same for me in Chrome Version 53.0.2785.101.

It helped to delete Key::TAB in line 681

$value = str_repeat(Key::BACKSPACE . Key::DELETE, $existingValueLength) . $value . Key::TAB;

... as already said above. But untested in current Firefox.

[kwoxer]

Also #194 seems to be identical.

[cocciagialla]

@lifeofguenter it seems that the TAB doesn't work only for password type inputs.

For example, this worked for me:

// Add the TAB key to ensure we unfocus the field as browsers are triggering the change event only
// after leaving the field.
$value = str_repeat(Key::BACKSPACE . Key::DELETE, $existingValueLength) . $value;
if ($elementType != 'password'){
   $value .= Key::TAB;
}

I think is not a BC break to exclude only password type.

[aik099]

@cocciagialla , did #244 work for you as well? A bonus side effect from #244 is ability to test jQueryUI.Autocomplete and similar controls.

[cocciagialla]

@aik099 yes it works perfectly. I hope it will be merged soon.

[aik099]

Just merged #244. Happy test running.