sendkeys() writes in the browser address bar instead of the input field

[lukeis]

Originally reported on Google Code with ID 6368

I use sendkeys on a certain input field, but the keys are actually writter in the address
bar.

What steps will reproduce the problem?
1. Get the page http://www.barrheadtravel.co.uk/
2. Find the input element by xpath //*[@id='1']
3. Execute:
actions.moveToElement(element).click().perform();
actions.sendKeys("text").perform();

What is the expected output? What do you see instead?

The input field remains untouched, but the "text" is appended to the address bar on
the browser.

Selenium version: 2.35.0
OS:Ubuntu 12.04
Browser: Firefox 
Browser version: 18.0.1

Reported by giovannigrasso on 2013-10-04 21:34:46

[lukeis]

Reported by barancev on 2013-10-07 07:59:03

• Labels added: Browser-Firefox

[lukeis]

Is the issue still actual in the latest selenium version (2.42 at the moment)?

Reported by barancev on 2014-06-30 22:49:28

• Status changed: NeedsClarification

[lukeis]

Have the same issue on 2.37. Will try upgrading to 2.42 and see if it happens there.

Reported by sstrannik on 2014-07-03 00:16:34

[lukeis]

Still occurs in 2.42
Using Firefox 24.6 ESR

The issue is exactly as described here:

http://code.google.com/p/selenium/issues/detail?id=2487

When our tests try to populate the username and password the username sometimes ends
up in the address bar instead of the username field.

The workaround suggested in issue 2487 somewhat reduced the frequency of this occuring,
but didn't fix it completely.

Code sample:

        String loginUrl = driver.getCurrentUrl();
        TestUtils.waitForMillis(5000);
        WebElement usernameField = getUsernameField();
        usernameField.clear();      
        usernameField.sendKeys(username);
        getPasswordField().sendKeys(password);
        TestUtils.waitForMillis(5000);
        clickLoginButton();

The odd thing is that it doesn't happen all the time, in a suite of 5 tests sometimes
all of them pass, most of the times 1 would fail, occasionally more than 1 would fail.

Reported by sstrannik on 2014-07-03 03:19:07

[lukeis]

I observe this same behavior bug where text gets input into the address bar on the latest
Selenium + Firefox:

Selenium version: 2.42.2
OS:Mac OS X 10.9.2
Browser: Firefox 
Browser version: 30.0

The bug doesn't appear in Chrome nor does it surface in the Python bindings for Selenium
(which I'm porting from). 

Reported by edmond@quip.com on 2014-07-04 01:17:44

[lukeis]

The bug is easily reproducible with some small modifications on the example Google test
case in the repro (example/google_search.js).

If instead of:

driver.findElement(webdriver.By.name('q')).sendKeys('webdriver');

we did:

driver.findElement(webdriver.By.name('q')).click();
driver.actions().sendKeys('webdriver').perform();

The text "webdriver" ends up in the address bar instead of the search box.

A self-contained reproducible test case looks like:

var webdriver = require('..'),
    SeleniumServer = require('../remote').SeleniumServer;

var server = new SeleniumServer("ext/selenium-server-standalone-2.42.2.jar", {
    port: 4444
});

server.start();

var driver = new webdriver.Builder().
    withCapabilities(webdriver.Capabilities.firefox()).
    usingServer(server.address()).
    build();

driver.get('http://www.google.com');
driver.findElement(webdriver.By.name('q')).click();
driver.actions().sendKeys('webdriver').perform();

driver.findElement(webdriver.By.name('btnG')).click();
driver.wait(function() {
  return driver.getTitle().then(function(title) {
    return 'webdriver - Google Search' === title;
  });
}, 1000);

driver.quit();
server.stop();

Reported by edmond@quip.com on 2014-07-08 01:04:31

[lukeis]

Reported by luke.semerau on 2015-09-17 17:45:55

• Labels added: Restrict-AddIssueComment-Commit

[lukeis]

Native events are deprecated and deleted from FirefoxDriver.

Reported by barancev on 2015-09-22 08:29:06

• Status changed: Fixed
• Labels removed: Status-Untriaged