Capybara: MWEB: Clicking is not clicking on the correct elements, even though it has the exact element. New to Chrome 67.

[nils-e]

Meta

(Updated these since initial posting)
Capybara Version: 3.0.0
Cucumber 2.4.0
Driver Information (and browser if relevant): selenium-webdriver (3.12.0)
Chrome 67 with chromedriver 2.39

Expected Behavior

Clicking to work as on chrome 66.

Actual Behavior

I am using chrome with mobile emulation. Nothing changed except for chrome autoupdated from 66 to 67. Now click is completely off on chrome 67. I tried the .click, click_on, .send_keys(:enter). Nothing seems to want to click the correct element besides manually clicking it. Click in automation still works perfectly on desktop. I actually think this may be a chrome bug, but I wanted to check here first.

Here is our site if you want to take a look at it -> https://www.shopstyleqa.com/

Code

Given(/^I click the login button$/) do
   el= find("ss-button", :text=>"Log In")
  puts el.inspect #this is to check the correct element is found
  el.click
end

Given(/^the login modal appears on mweb$/) do
  find("ss-auth-form", :visible=>:all)
...
end

Output

And I click the login button                      
      #<Capybara::Node::Element tag="ss-button" path="/html/body/app-root/ss-reframe-header/div[1]/div[2]/div[1]/ss-auth-buttons/div/div/ss-button[2]">
And the login modal appears on mweb               
      Unable to find css "ss-auth-form"
...

[twalpole]

Without some kind of example of this occurring there is absolutely nothing we can do here. Closing until an example is provided

[twalpole]

Also selenium-webdriver 3.4 and Capybara 2.15 are pretty out of date.

[nils-e]

@twalpole Let me try to get an example, but basically any time we use .scrollIntoView() and click; the element we click on is like it never scrolled, although I can check the element found by find() is correct. So the click registers on one that is usually way above the current element

[nils-e]

We will also check if updating will block us, but thank you and we will look into doing that

[twalpole]

@nils-e See https://github.com/teamcapybara/capybara/issues/2044 for a way to produce a good example if you don't have a publicly available one.

[nils-e]

@twalpole updated. if it is good and valid, can we reopen?

[twalpole]

@nils-e I can't replicate the issue with the information given. If you provide enough info to replicate it and it is an issue Capybara can do anything about then I will definitely reopen this. Here is starting code that does what your info shows but passes

require "capybara/dsl"
require 'selenium-webdriver'

sess = Capybara::Session.new(:selenium_chrome)
sess.visit('https://www.shopstyleqa.com/')
sess.find("ss-button", :text=>"Log In").click
sess.assert_selector(:css, "ss-auth-form")

If you can change that code to match your scenario so it fails (update to register with whatever settings you are using for chrome, etc) then there'll be something I can start looking at.

[twalpole]

@nils-e Ok I managed to replicate this using the below code

require "capybara/dsl"
require 'selenium-webdriver'

Capybara.register_driver(:selenium_mobile) do |app|
  mobile_emulation = { "deviceName" => "iPhone 8" }
  caps = Selenium::WebDriver::Remote::Capabilities.chrome("chromeOptions" => { "mobileEmulation" => mobile_emulation })
  Capybara::Selenium::Driver.new(app, browser: :chrome, desired_capabilities: caps)
end

# sess = Capybara::Session.new(:selenium_chrome)
sess = Capybara::Session.new(:selenium_mobile)
sess.visit('https://www.shopstyleqa.com/')
sess.find("ss-button", :text=>"Log In").click
sess.assert_selector(:css, "ss-auth-form")

and there's really nothing Capybara can do about it. It appears to be an incompatibility between the current version of chromedriver and Chrome 67 for any elements inside an absolutely positioned element. If one removes the absolute positioning everything works properly again. Report it to the chromedriver project and hope they fix it in the next release.

[nils-e]

@twalpole you are an amazing help. thank you so much. I reported it to the chromedriver project just now. I suspected it was a chromedriver issue, but I wasn't certain. Thanks for your time.

[nbeloglazov]

@nils-e do you have a link to any bug/thread which people can track?

[nils-e]

@nbeloglazov ya i do. There is this link and i keep checking the github repo for chromedriver. The last few comments somewhat confuse me, but I can imagine this bug is hitting a lot of people now as they are being forced to upgrade to Chrome 67 by the autoupdate feature. I am just blocking the update server and i rolled back to chrome 66 for now.
https://bugs.chromium.org/p/chromedriver/issues/detail?id=2452

[nils-e]

There was a reply here, but I am not informed enough about how to run this so I am just sending the message. @twalpole @nbeloglazov

https://bugs.chromium.org/p/chromedriver/issues/detail?id=2452#c23

Looks like the issue is related to your Ruby code on Mac. It seams to be "capybara/dsl" Ruby gem is different from what is in Linux, because your Ruby code works on Linux but it doesn't work on Mac OS X. Please try to run the same scenario with the following Java code and see if it works:

public class Issue2452 {
    public static void main(String[] args) throws Exception {
        try {
            String driverPath = "/<path>/chromedriver";
            System.setProperty("webdriver.chrome.driver", driverPath);
            System.setProperty("webdriver.chrome.logfile", "/<path>/Issue2452.log");
            System.setProperty("webdriver.chrome.verboseLogging", "true");
            Map<String, Object> mobileEmulation = new HashMap<>();
            mobileEmulation.put("deviceName", "Nexus 5");
            ChromeOptions chromeOptions = new ChromeOptions();
            chromeOptions.setExperimentalOption("mobileEmulation", mobileEmulation);
            ChromeDriver driver = new ChromeDriver(chromeOptions);
            driver.get("https://www.shopstyleqa.com/");
            Thread.sleep(2000);
            WebElement el = driver.findElement(By.tagName("ss-button"));
            el.click();
            driver.quit();
        } catch (Exception e) {
            System.out.println("!!! Exception !!!");
            System.out.println(e);
        }
    }
}

If you get a repro with Java code please attach Issue2452.log file to this bug and share your repro code.

[twalpole]

That response makes 0 sense -- what difference would language make - and the java code given doesn't actually check for the existence of the result of clicking the button

[gerrywastaken]

For anybody searching this issue using Chromedriver and mobile emulation:
https://bugs.chromium.org/p/chromedriver/issues/detail?id=2144&desc=2#c50

A workaround for this bug would be something along the lines of:
page.execute_script("arguments[0].click()", find(selector))

[twalpole]

@gerrywastaken That workaround can be written more succinctly using a reasonably recent release of Capybara as

find(selector).execute_script("this.click()")

However, one should fully understand that by using these workarounds you may no longer necessarily be testing what a user can actually do and it may make your test pointless. Obviously when running into an issue like this one with chromedriver/chrome it may be necessary in order to test anything, but it should only be used for those specific clicks where it is necessary and only until chromedriver/chrome fixes itself.

[summera]

It looks like they've released a new version of chromedriver (2.42) with a fix, however I'm still having issues clicking an element that is position: fixed when using mobile emulation after updating 2.42. Anybody else still having issues?

[twalpole]

@summera Is it the same behavior - the click occurs at the wrong location? or are you getting an error when attempting to click? Also, can you provide a reproducible example?

[nils-e]

@twalpole @summera just checked and it is still failing the original STR here https://bugs.chromium.org/p/chromedriver/issues/detail?id=2452

My test is clicking on a different spot than it is supposed to. It passes in chrome 66 and older chromedriver config. Reverting back now.

[twalpole]

Yeah -- apparently the chromedriver issue wasn't fixed in 2.42 - not really clear how the chromedriver team assigns priority of which issues to fix.