Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

HTML includes XML declaration and DOCTYPE on 64 bits Ruby, and breaks spec #597

gaizka opened this Issue Jan 8, 2012 · 4 comments


None yet
3 participants

gaizka commented Jan 8, 2012

Hi there!

This is a duplicate of issue jnicklas#570 , but I am attaching a failing spec and I'll try to explain why I think this is a real issue.

I've attached a failing spec here: https://gist.github.com/1578175

In that issue, @jnicklas closes the issue telling that browsers won't bother about that.

The problem is that because of Nokogiri (or Capybara interacting with it, i am not sure where is the real problem) inserts that xml declaration, Capybara parsing breaks and some of my specs are failing.

Every spec where we test that we have some content, and this content contains accented characters (áéíóú), or where we test that we have a html tag (for example, <iframe></iframe>) that with the xml declaration get converted to <iframe />.

The attached spec works properly in my laptop (capybara 1.1.1, nokogiri 1.5.0, rack 1.2,5, rack-test 0.5.7, ruby 1.9.2p180), but fails in my CI server (same version of every gem, ruby, etc, only difference is that is a 64 bit machine).

I'll try to find the problem.


jnicklas commented Jan 8, 2012

I disagree. Capybara has ways of asserting that the stuff you want to be on the page, actually is on the page. There's has_selector?, find, all and a number of other useful tools, just read the README. Regexp matching against the output of page.body is not how you're supposed to use Capybara. If you're unsure why, please read this thread: http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags. You should regard the output of page.body as debug information for the current state of the DOM. Nothing more.

gaizka commented Jan 8, 2012

My mistake then, sorry for the noise. I was used to spec this way sometimes.

The README says:

If all else fails, you can also use the page.html method to test against the raw HTML:

page.html.should match /<span>.../i

Maybe you could consider that this is only a debugging information, and avoid building specs this way.

Also, thanks a lot for Capybara, it helps so much building robust web apps!!!

@gaizka gaizka closed this Jan 8, 2012

@joliss joliss added a commit that referenced this issue Jan 8, 2012

@joliss joliss Advertise page.html in the Debugging section, not in the Querying sec…

As suggested by @jnicklas and @gaizka in #597.

joliss commented Jan 8, 2012

The README says: ...

Good point, that's a bit misleading there. I've fixed it in c4247f9.


jnicklas commented Jan 8, 2012

Thanks Jo!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment