:first-child broken with libxml 2.9.0

[betelgeuse]

A test suite for my application started failing and I think this is due to upgrading libxml to 2.9.0. It seems nokogiri is not able to do first-child properly with it atm:

1.9.3-p327 :007 > Nokogiri::XML('<foo><bar/></foo>').css('bar:first-child')
 => [] 
1.9.3-p327 :008 > Nokogiri::XML('<foo><bar/></foo>').css('bar')
 => [#<Nokogiri::XML::Element:0x11826430 name="bar">] 

[betelgeuse]

verified by downgrading:

WARNING: Nokogiri was built against LibXML version 2.9.0, but has dynamically loaded 2.8.0
1.9.3p327 :001 > Nokogiri::XML('<foo><bar/></foo>').css('bar:first-child')
 => [#<Nokogiri::XML::Element:0x5ed69c6 name="bar">] 

[lucasgertel]

How did you downgraded libxml?

[betelgeuse]

@lucasgertel using the package manager of my Linux distribution (emerge on Gentoo)

[rapimo]

+1 for me also nth-child(n) seems to be broken with libxml 2.9.0

[flavorjones]

Please note that Team Nokogiri hasn't made any effort yet to support libxml 2.9.0. It's next on my list after we release 1.5.7.

[Themitchell]

The problem seems odd. comparing on another machine running 2.8.0 works normally. In 2.9.0 it appears that a blank node is found for each odd :nth-child. You can see the debugger output to prove this issue

https://gist.github.com/Themitchell/5135296

So 1st, 3rd and 5th nodes work which should be 1st, 2nd and 3rd (and indeed are correctly returned as 1st, 2nd, 3rd on a 2.8.0 system)

Hope that gives a little more context on the issue.

[flavorjones]

This appears to be a bug in libxml 2.9.0. I will be submitting a bug report to Daniel Veillard today. In the meantime, downgrade to 2.8.0 if you can.

[flavorjones]

To be specific, it appears that the xpath function position() is off-by-one. Keeping in mind that Nokogiri transforms CSS to XPath:

puts Nokogiri::CSS.xpath_for("foo[2]")           # => "//*[position() = 2 and self::foo]"
puts Nokogiri::CSS.xpath_for("foo:nth-child(2)") # => "//*[position() = 2 and self::foo]"

We can run the following script:

xml = <<EOXML
<root>
  <foo>1</foo>
  <foo>2</foo>
  <foo>3</foo>
  <foo>4</foo>
</root>
EOXML

doc = Nokogiri::XML xml

puts Nokogiri::VERSION_INFO["libxml"]

%w{foo[1] foo[2] foo[3] foo[4]}.each do |css|
  puts "---- #{css}"
  puts (doc.at_css(css) || "")
end

and for 2.8.0 and 2.9.0 get the following (different) outputs:

{"binding"=>"extension", "compiled"=>"2.8.0", "loaded"=>"2.8.0"}
---- foo[1]
<foo>1</foo>
---- foo[2]
<foo>2</foo>
---- foo[3]
<foo>3</foo>
---- foo[4]
<foo>4</foo>

and

{"binding"=>"extension", "compiled"=>"2.9.0", "loaded"=>"2.9.0"}
---- foo[1]

---- foo[2]
<foo>1</foo>
---- foo[3]
<foo>2</foo>
---- foo[4]
<foo>3</foo>

[flavorjones]

Bug reported to libxml2 here: https://bugzilla.gnome.org/show_bug.cgi?id=695699

[ghostganz]

The bug reported on libxml2 is resolved as NOTABUG.

[flavorjones]

OK, so the libxml2 team is saying that the XPath queries in 2.8.x and earlier releases of libxml2 are buggy, and 2.9.0 is doing the right thing:

https://bugzilla.gnome.org/show_bug.cgi?id=695699#c3

So I'm going to (gag) put in a libxml2-version-specific workaround (gag).

[flavorjones]

Hmm. I'm pushing back against the libxml2 list on this one. Libxml 2.9.0 is the only implementation I can find with behavior, which makes it suspect. Hang tight and I'll let you know how it progresses.

[flavorjones]

Please note that Daniel has confirmed that this behavior appears to be a bug in libxml 2.9.0.