.click broken for Selenium 3

[MartinSoeesJohansen]

As with Selenium 3 and the need of geckodriver for web browser testing the .click() is broken. Environment: Windows 7 Firefox 49.0.2 GeckoDriver 11.1-64bit Selenium 3.0.1 Python 3.5.2

Elements can be found by Selenium either by xpath, css or link text, but .click() is not performed. Please see the Stack link for a detailed explanation of what I've done so far.

EDIT: it seems to be working on pages without heavy javascript source code. So it might be geckodrivers ability to handle javascript?? This page works: www.dr.dk This page doesn't work: www.phptravels.com/demo

A longer, thorough, explanation can be found on Stack here

[AutomatedTester]

I was able to reproduce. However, hitting return on the element works

from selenium import webdriver
f=webdriver.Firefox()
h=f.find_element_by_xpath("//a[@href='//www.phptravels.net/admin']")
h.click()
from selenium.webdriver.common.keys import Keys
h.send_keys(Keys.RETURN)

[MartinSoeesJohansen]

Great that Keys.RETURN works, thank you. I'll try and implement that, but shouldn't it still be possible to use .click? It sucks to be having to write hacks for Firefox because geckodriver doesn't work properly.

[andreastt]

@AutomatedTester Do you have an idea what’s wrong here so we can file a Marionette bug?

[AutomatedTester]

I havent looked into the html, but feels like there might be something is catching the click that shouldnt be or something like that

[danhumphrey]

I have experienced a number of issues where GeckoDriver and Selenium 3 clicks are broken when they are working in other browsers, however, I don't have a public reproducible test case :(

In my case, I have clicks which:

• Work in all browsers (including Firefox) using Selenium 2.53.1
• Work in Chrome and Edge using Selenium 3.0.1

but do not work with GeckoDriver 0.11.1 with FF Nightly or FF 49.0.2

In my case the element is found and there are no exceptions thrown - the click simply has no effect.

I'm attempting to find a public demonstration of this, which led me to this issue, however, in this instance, I am getting an ElementNotVisibleException with the following code:

driver.get("http://phptravels.com/demo.php/");
WebElement element = driver.findElement(By.xpath("//a[@href='//www.phptravels.net/admin']"));

//I thought moveToElement might help but this doesn't appear to be implemented in GeckoDriver yet 

//Actions actions = new Actions(driver);
//actions.moveToElement(element);
//actions.click();
//actions.perform();

element.click();

[demisk]

The problem I'm seeing is with clicking on text fields. Calling element.click() changes the current active element (document.activeElement), but it seems that focus events are not firing.

For example, given the URL [http://phoenix.pslc.cs.cmu.edu/QA/Tutors_trunk/html5_interfaces/fractionAddition.html?tutoring_service_communication=javascript&question_file=http://phoenix.pslc.cs.cmu.edu/QA/Tutors_trunk/html5_brds/FractionAddition/1213.brd],

the following code worked in Selenium 2, but it does not work in Selenium 3 with the gecko driver (i.e., the text in e1 does not turn green):

WebElement e1 = driver.findElement(By.id("ctatdiv26"));
e1.click();
e1.sendKeys("6");
WebElement e2 = driver.findElement(By.id("ctatdiv32"));
e2.click();
// assert text in e1 is green

[aviita]

I am using C# for programming Selenium tests.

For me the following code works (so without gecko driver?):

FirefoxDriverService service = FirefoxDriverService.CreateDefaultService();
service.FirefoxBinaryPath = @"C:\Program Files (x86)\Mozilla Firefox\firefox.exe";
IWebDriver driver = new FirefoxDriver(service);

And this does not work (with gecko driver):

IWebDriver driver = new RemoteWebDriver(new Uri("http://localhost:4444/wd/hub"), DesiredCapabilities.Firefox(), TimeSpan.FromMinutes(10));

I have 64 bit version of gecko driver (geckodriver-v0.11.1-win64) and the gecko driver seems to be launching 32 bit version of firefox. The test works up until the first Click event.

I can see that there is this stange opacity on the page where the click does not work. Additionally the click does not work even when continuing to to use the browser with mouse like you normally would. If I hit return on the page, I get to the next page and the opacity disappears. On the second page the click once again operates normally when used with a mouse.

If I add the SendKey, the rest of the test goes through just fine: driver.FindElement(By.ClassName("js-newdesign-wizard-next")).SendKeys(Keys.Return);

[AutomatedTester]

If anyone can help reduce the HTML needed to get this issue fixed that would help us fix it quickly.

[jsaltz]

This code works for Chrome: actions.MoveToElement(element).Perform(); Browser.Instance.FindElements(click).FirstOrDefault()?.Click();

But results in this error for Gecko: An exception of type 'System.NotImplementedException' occurred in WebDriver.dll but was not handled in user code Additional information: POST /session/c66773d7-38a6-4616-b771-e605b9c201c4/moveto did not match a known command

I've not yet found a workaround to implement a click on an anchor link. Trying to bypass MoveToElement and Click() with SendKeys - Browser.Instance.FindElements(click).FirstOrDefault().SendKeys(Keys.Return); --just ends up throwing this: An exception of type 'OpenQA.Selenium.ElementNotVisibleException' occurred in WebDriver.dll but was not handled in user code

It's the MoveToElement that's broken in this driver. Any ETA for a fix to this?

[danhumphrey]

@jsaltz the NotImplementedException means literally that - Actions are not yet implemented in geckodriver. This issue is highlighting a problem where an element is found (is visible and clickable), but the click method has no effect and no Exceptions are thrown.

[jsaltz]

I got a jquery workaround for this. In a block after determining the browser is Firefox I have: IJavaScriptExecutor js = Browser.Instance as IJavaScriptExecutor; //NOTE: Browser.Instance is my IWebDriver = new FirefoxDriver() var TheAnchorTag = Browser.Instance.FindElements(TheAnchorTagYouWantToClick).FirstOrDefault(); string jsScript = "$( document ).ready(function() { " + "window.location.href = $(\"a:contains('" + TheAnchorTag.Text + "'):last\").attr(\"href\");" +
"});"; js.ExecuteScript(jsScript);

Fun at the old Firefox ballpark

[caladd]

Here is a crude workaround for the click not pausing long enough for the page to fully load:

from time import sleep
from selenium import webdriver
from selenium.webdriver.support.events import EventFiringWebDriver, AbstractEventListener

class EventListener(AbstractEventListener):
    def after_click(self, element, driver):
        sleep(1)

driver = EventFiringWebDriver(webdriver.Firefox(), EventListener())

[heyrex]

I can confirm many, many troubles sending clicks. It's particularly bad with radio buttons and checkboxes but has also manifested on list items, hrefs and input type=submit.

In some cases I've been able to work around by scrolling the item further into the viewport using a window.scrollTo() or window.scrollBy() JS call. Other times I'm just completely stuck and have to send key presses instead.

I've noticed that at certain times of day I can click something and at other times (randomly) I cannot. Our entire collection of test suites passes flawlessly against Chrome.

Firefox: 50.0.2 Geckodriver: 0.11.1 Selenium: 3.0.1 Windows 7 64 bit

[dylanlive]

I'm replicating this issue as well. It seems geckodriver can't click game elements (.game-item) from www.twitch.tv/directory

Specs: Firefox: 50.1.0 Geckodriver: 0.13.0 Selenium: 3.0.5 OS: macOS 10.12.2

Example in Capybara:

visit 'https://twitch.tv/directory'
first('.game-item').click

geckodriver Debug Logs:

-> POST session/887dc33d-302a-eb46-ac1c-f2c0fa3b2573/element/6c9c7ca7-a9ec-f14f-af4e-2091187fb62d/click
1484251211336   hyper::server   DEBUG   Incoming stream
1484251211336   hyper::server::request  DEBUG   Request Line: Post AbsolutePath("/session/887dc33d-302a-eb46-ac1c-f2c0fa3b2573/element/6c9c7ca7-a9ec-f14f-af4e-2091187fb62d/click") Http11
1484251211336   hyper::server::request  DEBUG   Headers { Accept: application/json, Content-Length: 2, Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3, User-Agent: Ruby, Connection: close, Host: 127.0.0.1:4444, Content-Type: application/x-www-form-urlencoded, }
1484251211337   webdriver::server   DEBUG   Got request POST AbsolutePath("/session/887dc33d-302a-eb46-ac1c-f2c0fa3b2573/element/6c9c7ca7-a9ec-f14f-af4e-2091187fb62d/click")
1484251211337   webdriver::command  DEBUG   Got request body {}
1484251211337   geckodriver::marionette DEBUG   → 66:[0,8,"clickElement",{"id":"6c9c7ca7-a9ec-f14f-af4e-2091187fb62d"}]
1484251211365   geckodriver::marionette DEBUG   ← [1,8,null,{}]
1484251211365   webdriver::server   DEBUG   Returning status Ok
1484251211365   webdriver::server   DEBUG   Returning body {}
1484251211365   hyper::server::response DEBUG   writing head: Http11 Ok
1484251211365   hyper::server::response DEBUG   headers [
Headers { Connection: close, Content-Type: application/json, Content-Length: 2, Date: Thu, 12 Jan 2017 20:00:11 GMT, }]
1484251211365   hyper::server::response DEBUG   write 2 bytes
1484251211365   hyper::server   DEBUG   keep_alive = false for 127.0.0.1:50500
1484251211365   hyper::server   DEBUG   keep_alive loop ending for 127.0.0.1:50500
<- {}

I've also done typical debugging such as adding sleeps, etc. An element gets returned upon clicking, but the click doesn't go through.

As described above, sending the enter key works.

visit 'https://twitch.tv/directory'
top_game = first('.game-item')

top_game.click
top_game.send_keys(:enter)

[andreastt]

@dylanlive When you say it “can’t click elements”, what do you expect to happen when the element has been clicked? For a new page to load, or for the DOM state to change?

I’m quite sure that in both cases the clicks do happen, but that it in the first case does not wait for the new document to load, and that it in the latter case works just fine.

[dylanlive]

@andreastt Thanks for responding. DOM updates on click - there's no full page reload. If you mean a coded expectation, while debugging this, I'm not making any. I've hardcoded a 5 second sleep to visually ensure the click occurred.

Here comes an info dump...

I've been experimenting a lot today, and found a fix for my specific case - I had to refer to a class a few levels up in the DOM.

URL: https://twitch.tv/directory

• Clicking: .js-directory-game works
  • .tower .js-directory-game:nth-of-type(1) if not using Capybara's first() method
• Clicking: .game-item does not work
  • .tower .js-directory-game:nth-of-type(1) .game .game-item if not using Capybara's first() method.

It's intriguing, because the Ember action and href is associated with the .game-item element -- not the div. I can validate the .game-item is returning a valid element, and verified its Title attribute is correct... click just doesn't seem to work.

[1] pry(#<RSpec::ExampleGroups::Test>)> first('.game-item')['title']
=> "League of Legends"

DOM Structure:

I converted my example to a Selenium Ruby script, perhaps for easier replication.

Example of the .click method, not working:

require 'selenium-webdriver'

caps = Selenium::WebDriver::Remote::Capabilities.firefox marionette: true
driver = Selenium::WebDriver.for :firefox, :desired_capabilities => caps
driver.navigate.to 'https://www.twitch.tv/directory'

sleep(3) # Just to be safe...
element = driver.find_element(:css, '.tower .js-directory-game:nth-of-type(1) .game .game-item')
element.click

puts 'ELEMENT CLICKED. Sleeping for 5 seconds.'
sleep(5) # Verify visually if the dom changed
driver.quit

Example of the .send_keys method, working:

element = driver.find_element(:css, '.tower .js-directory-game:nth-of-type(1) .game .game-item')
element.send_keys :enter

If you downgrade to Firefox 45.6.0, and set marionette to false in the above scripts, you'll see the click script works, so I'm fairly certain something changed in behavior with geckodriver (whether it's truly a bug... not yet sure).

Also noticed the Javascript Click event will work: $('.tower .js-directory-game:nth-of-type(1) .game .game-item').click();

[joshipratik]

Even I am facing issue with click. I have noticed that when this issue is seen, URL area is highlighted in "blue", the cursor is in the URL text area.

If I click inside the client area in the browser (anywhere) (before click call), the click is send properly.

[bjharo]

Just wanted to add that I've encountered the same issue with random click failures using the latest release of geckodriver and FF 51. My tests work flawlessly on FF 47 (with the old driver), Chrome, and IE 11 but FF 51 and geckodriver are a no go.

I've tried using the Keys.RETURN trick and sending a javascript click with various success. It clears up some of the problems and but tends to create others.

[danhumphrey]

Agree with the comment by @joshipratik above - the URL bar (awesome bar?) is highlighted in blue. If I add a sleep before the click and manually click (set focus to) the page, then the previously failing click works as expected.

[andreastt]

@joshipratik @danhumphrey Focus on the address bar seems to be a separate issue? That in particular was reported in https://github.com/mozilla/geckodriver/issues/394 and fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1328676 in Firefox 52 onwards.

[danhumphrey]

confirmed @andreastt - updating Nightly resolved it. Thanks!

[Frankstar]

the Focus on the address bar seem to be fixed, but not the inital Problem of this issue (.click() ) Any ETA on this? it looks like ist working from time to time. I can close the browser, and start a new one and its working. close it again and test it and its not working.

Oh and its not only the .click() - for me the same issues is for send_keys() Same time .maximize_window() is always working - as example.

Tested with latest gecko and aurora.

Very annyoing for tests :(

[nurp]

.click, .sendKeys(KEYS.ENTER), .sendKeys(KEYS.RETURN)

• works for me when I connect to exactly same site served at http://localhost:8001,

• doesn't work when I access it at http://example.com/test

(on Firefox 51.0.1 (64-bit), Mac OS)

[dwt]

Perhaps this helps in debugging this: for me it seems that simply repeating the click event (normal hyperlink) seems to help very much.

i.e. I now have this in some places in my code:

# workaround for https://github.com/mozilla/geckodriver/issues/322
# where the click sometimes is swallowed. Should be fixed in the comming weeks
self._find_element(By.LINK_TEXT, "Vorschau").click()
self._find_element(By.LINK_TEXT, "Vorschau").click()

[git-randy]

I'm using Selenium 3.4.1, Firefox 53.0.2, and geckodriver 16.1. Navigating to the site agendaweek.com (screenshot below), I was able to click this log in button in Selenium 2.53.6 but now I can't. The click action goes through and proceeds to the next line of code so no errors are given but in reality, the button does not get clicked on.

[andreastt]

@AlphaTangoFoxtrot Please file a separate bug with a reproducible test case.

[heyrex]

@AlphaTangoFoxtrot This is exactly the problem I am seeing too.

@andreastt can you elaborate on what your requirements for reproducibility and repeatability are?

This bug only manifests randomly for me. I've tried running a suite of tests on 5 identical cloned virtual machines and each one exhibited symptoms at different points in the suite or not at all. The only apparent correlation I could find was overflow scrolling. This seems like it could be a race condition, but how do you create a test case that reliably reproduces that? (genuine question)

[WonderWoman01]

Was a new ticket create for this issue, seems I'm also having the same problem?

[AutomatedTester]

@AlphaTangoFoxtrot I have done a quick investigation and can recreate the issue. I think I know what could be the cause. I will do more investigating and document it here

[WonderWoman01]

So glad you were able to recreate the issue. Any updates as this is holding us back from performing any Firefox testing at the moment.

[whimboo]

@AutomatedTester do you have more details about what you found out? Would be good to get a bug filed about it for Marionette.

[jadonant]

Has this been fixed?

[Frankstar]

@jadonant no

[whimboo]

I just checked the case from @AlphaTangoFoxtrot and found one issue we have in click(). This might also be related to others seeing it, but to say that I would need trace logs from geckodriver.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1374283 and will have a look at this.

[whimboo]

@MartinSoeesJohansen, you as creator of the issue could you please attach such a trace log, or tell which elements you click on for the pages mentioned in the original comment?

[MartinSoeesJohansen]

I've been away from this for too long. Can't attach a trace log or recall the elements I interacted with. Perhaps some of the other commentators can contribute?

[heyrex]

@whimboo Regarding your comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1374283#c1 We maintain a site which uses DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" and also has display:block elements which occur close to nodes having click failures. I could try and produce a trace if you point me to some information on what tool/config options are required for the trace.

[whimboo]

@heyrex, a trace won't help here given that the click is just not happening on the real element and as such doesn't produce any helpful output. What you could try is to save the page via "Webpage, complete" so it contains all referenced files. Then try to load it via localhost. If it still fails try to remove the doctype, or the display:block rule for the element which fails to click. If that works, we can be sure it's the same underlying issue.

[whimboo]

What do you mean with 3.5. This is a bug in Marionette which will have to be fixed in Firefox. Please see the former comments. Thanks.

[dmholb01]

Has this issue ever been fixed with geckodriver or has anyone found a solution or workaround for their automation? I'm seeing this exact same problem.

[whimboo]

@MartinSoeesJohansen, I had a look at your issue today with Firefox versions starting with 55.0 up to 57.0a (Nightly) and I cannot reproduce your issue anymore. Can you please check that it works for you now too?

For all others, please upgrade to the latest Firefox and geckodriver release, and test your code again. If click is still not working in some cases, then file a new issue with concrete steps. A "I see it too" is not helpful at all. Thanks.

[ghost]

Just to mention what worked for me, as I had the same issue, some regions get clicked, others not: For instance, "findElement(By.linkText" works fine, but in my case, I needed to find it by an id (never mind). I called click two times in a row and it now works, not sure what the problem was. My Firefox is 54.01. (32 bit), on Windows 10 (64). The gecko is v0.18.0

[andreastt]

@g000dy Firefox 54 is probably too old, as the fixes @whimboo refer to landed more recently. Can you please try again with Nightly (57 or greater)?

[ghost]

The firefox update (and any updates for that matter) are a complicated procedure in our company. Let's just say, I updated to 55.0.2 (32-bit) and it now works. Not sure if it had something to do with the firefox itself to be honest, but it might be the cause ...

[andreastt]

@g000dy geckodriver itself is just a simple HTTPD that provides the WebDriver API. It proxies calls to the Marionette remote protocol in Firefox, where most of the heavy lifting goes on.

This means that most fixes we make to improve our WebDriver support happens in Firefox. geckodriver is however not tied to a particular version of Firefox because they communicate over a transparent remote protocol.

[adamjson]

@g000dy You mentioned clicking twice in a row. I've also run into a scenario where the first button click consistently fails and the second click succeeds. I'll see if I can come up with a consist test case.

[whimboo]

A testcase would be great. I think that this issue might be related with bug 1394354 for Marionette.

[JamiePendleton]

We are seeing this issue with webdriver.js For example clicking links on a navbar seems to focus on the link however the click never happens. I've read a lot in this post and it seems like this currently is not working?

So far I've tried the following element.click() element.sendKeys(RETURN) 2 element.click() in a row. also tried the below executeScript code doclick(element) { return this.driver.executeScript("arguments[0].click();", element); }

Also, when I do the click, I've tried clicking our own Id, also bytag and by getattribute("href")

Selenium webdriver.js version 3.5 Geckodriver version v0.19.0

In my .then statement, I am passing the navigation bar links in (our data-auto value from our own product code). I log out the count to make sure I get them then I use the below code to click each one. What I see is each link highlight but no click happens where I should be brought to another page. This test is to click each link one after the other in a loop and then do something.

    .then((links) => {
      navigationlinks = links;
      const areThereToggles = [];
      for (let i = 0; i < links.length; i++) {
        links[i].click();
        //we fail here due to no click happening...the link highlights though as we go through each
        areThereToggles.push(this.areTocCheckboxIconsPresent());
      }
      return Promise.all(areThereToggles);
    })

The F12 underlying link looks like this. I've tried clicking on the as well as our own data-auto, href etc.

I took out the end tags <> so you can see the below

a class="_3ponYMwshNSq6kAmWIMfI1" data-auto="globalnav-link" href="/skills/browse/Nursing%20Skills">Nursing Skills</a

*Using Chrome, click works as expected

@JamiePendleton without a trace log and even better a HTML snippet to reproduce it we cannot help. So if you have one which permanently reproduces the problem please provide it to us. This would be totally helpful. Thanks.

[JamiePendleton]

I'll post more soon if need be, for now however on sauce labs, the same tests that were failing at click now work. I am not sure how yet, but the tests passed. I'll need to see if I can get a repro.