teamcapybara / capybara

Acceptance test framework for web applications

Home Page:http://teamcapybara.github.io/capybara/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Find with xpath does not find existing element. Find without xpath finds.

jlahtinen opened this issue · comments

Meta

Capybara Version:
capybara (3.39.2)
Driver Information (and browser if relevant):
Capybara::Selenium::Driver.new(
app,
:browser => :chrome,
:options => browser_options,
)

jruby 9.4.3.0

Expected Behavior

Both

find(:xpath, "//h3[contains(text(),'Some text')]")

and

find("h3", :text => 'Some text')

should work.

I have these in same scenario. find("h3", :text => 'Some text') before find(:xpath, "//h3[contains(text(),'Some text')]") and find("h3", :text => 'Some text') works fine.

Actual Behavior

find with xpath does not work

Capybara::ElementNotFound:
       Unable to find xpath "//h3[contains(text(),'Some text')]"
     # /home/jlahtinen/.rvm/gems/jruby-9.4.3.0/gems/capybara-3.39.2/lib/capybara/node/finders.rb:310:in `block in synced_resolve'
     # /home/jlahtinen/.rvm/gems/jruby-9.4.3.0/gems/capybara-3.39.2/lib/capybara/node/base.rb:84:in `synchronize'
     # /home/jlahtinen/.rvm/gems/jruby-9.4.3.0/gems/capybara-3.39.2/lib/capybara/node/finders.rb:301:in `synced_resolve'
     # /home/jlahtinen/.rvm/gems/jruby-9.4.3.0/gems/capybara-3.39.2/lib/capybara/node/finders.rb:60:in `find'
     # /home/jlahtinen/.rvm/gems/jruby-9.4.3.0/gems/capybara-3.39.2/lib/capybara/session.rb:773:in `find'
     # /home/jlahtinen/.rvm/gems/jruby-9.4.3.0/gems/capybara-3.39.2/lib/capybara/dsl.rb:52:in `find'

How to debug?

I could investigate this myself if you can give me any tips where to start looking.

This does not happen if I save output of the problematic page and serve that file without any dependencies like images or css or javascript. So I have problems to give a example where this can be tested.

I also have quite old project at hand so it is not too easy to upgrade all dependencies.

Given you're running this against a driver which processes CSS this is likely as expected - The two calls aren't doing the same thing. The one call is running pure XPath which runs directly against the document and therefore doesn't see any CSS applied to the page. The second call (with the :text option) is looking at the text as it's displayed on the page, and therefore will compare against the text as displayed. This means if you have any css like text-transform being applied to the text you need to match against what's actually shown to the user ('SOME TEXT', etc). Without knowing exactly what text you're matching against, and seeing an image of the page it's impossible to state that for sure, but I'm 90+% sure that's what you're experiencing (since others have had the same "issue"). If you provide evidence to show that's not what's going on we will reopen this.

Also note, you should get in the habit of "always" starting your xpath selectors with .// rather than // - see https://github.com/teamcapybara/capybara#beware-the-xpath--trap

@twalpole I understand that this is hard to accept as anything else than user error. Do you have any hints how to try to find where things can go wrong. If I search all elements and print text context of all of them it seems that text is there like expected.

I also noticed that contains(., 'Some text') works where contains(text(), 'Some text') does not. But I am almost 100% sure that element that I try to find contains only one text node 'Some text' and nothing else. Also saving page content and testing it for example with chrome I can find element with contains(., 'Some text') or with contains(text(), 'Some text').

@jlahtinen . and text() mean different things in XPath, and if they're returning different results it means 100% that there is not only one text node in the element you're querying. Capybara doesn't execute the XPath, it's passed to the browser to execute, so any XPath differences you think are a bug in Capybara aren't. Why are you insisting on trying to use XPath for these queries in the first place? Use CSS 99.9% of the time, it's easier to read, takes the user visible state of the page into account better, and has far fewer sharp edges than XPath