#395 ✓ resolved
Arpan

Opera 9.x XPath descendants bug

Reported by Arpan | October 18th, 2008 @ 01:43 AM | in 1.6.1

$$() doesn't seem to work properly in Opera 9.5 / 9.6

To duplicate, go to prototypejs.org and open Opera’s developer tools (Menu => tools => Advanced => Developer tools) and type the following in the console.

  • type $$(“li”).invoke(“hide”) => (all list items disappear)
  • type $$(“li”).invoke(“show”) => to show items again.

  • now type $$(“ul li”).invoke(“hide”) => again all list items should disappear. Instead only the ones in the first “ul” disappear. (Firefox & Safari correctly hide all list items here)

Comments and changes to this ticket

  • Juriy Zaytsev

    Juriy Zaytsev October 18th, 2008 @ 03:49 AM

    • Assigned user set to “Juriy Zaytsev”
    • State changed from “new” to “bug”
    • Milestone set to 1.6.1
    • Tag set to dom, opera

    I can reproduce this with 1.6.0.3 in Opera 9.6 (OSX)

  • Juriy Zaytsev

    Juriy Zaytsev October 18th, 2008 @ 04:55 AM

    Something weird is going on. The snapshotLength for the following xpath is 0 in Opera (with valid elements on a page):

    
    ".//*[local-name()='tr' or local-name()='TR']//*[local-name()='td' or local-name()='TD']"
    
    // in selector, it all boils down to:
    
    document.evaluate(".//*[local-name()='tr' or local-name()='TR']//*[local-name()='td' or local-name()='TD']", document.documentElement, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null)
    
    
  • Phred

    Phred October 20th, 2008 @ 07:02 PM

    Can anyone post a page that is not working as expected? I just checked this on a page with tables and it worked fine. Precisely the same xpath that Juriy Zaytsev pasted above. Works without a problem. Tried at twitter... where they still use tables for layout.

  • Juriy Zaytsev

    Juriy Zaytsev October 20th, 2008 @ 07:05 PM

    @fearphage

    Interesting. The bug was actually confirmed to me by "Remco" in #opera. He also mentioned it's a known one.

    I'll make a failing page asap.

    Thanks.

  • Juriy Zaytsev

    Juriy Zaytsev October 20th, 2008 @ 07:34 PM

    Ok, had to strip down prototype.js home page to a minimum failing one : )

    Here you go: http://yura.thinkweb2.com/js/bug...

  • Andrew Dupont

    Andrew Dupont October 20th, 2008 @ 08:28 PM

    I love Opera, but their XPath engine has driven me crazy with issues like this. Maybe we need to meet up with them and help with a test suite.

  • Phred

    Phred October 21st, 2008 @ 07:10 PM

    Can anyone explain to me why you would create that xpath expression instead of?

    
    './/tr//td'
    

    I'm curious. I was recently told that (x)html tags are always lowercase although I have no means to verify this either way. I always do xpath in lowercase (always).

    Another side note: Opera supports XML DOM from IE (Node#selectNodes and Node#selectSingleNode). This is faster than document#evaluate + convert to Array. Just a thought.

  • Andrew Dupont

    Andrew Dupont October 22nd, 2008 @ 03:56 AM

    • Tag changed from dom, opera to dom, opera, xpath

    I wrote the code that way because with that syntax you can have a 1:1 correlation between CSS tokens and XPath tokens.

    If you use the simplest XPath expressions, tr#foo would translate to .//tr[@id='foo'], but #foo would translate to .//*[@id='foo'].

    But we break up the CSS selector into tokens and parse each on its own, so the token that parses IDs doesn't know whether a tag name was specified before it. If not, it needs to add the * itself; if so, it shouldn't add anything.

    The simpler approach is to say that a descendant combinator translates to //*, a child combinator translates to /*, and so on — and then make each regular CSS token into an XPath criterion.

    I hope I explained that properly.

    We check both uppercase and lowercase because some browsers normalize the case and some don't. We support HTML 4 also, so we can't require that all tags be lowercase.

    Thanks for the note about Node#selectNodes. We'll probably keep the Opera implementation as-is, since it's already screaming fast. It's just a matter of getting the damned XPath to work properly.

  • Juriy Zaytsev

    Juriy Zaytsev October 31st, 2008 @ 12:32 AM

    @fearphage

    So is there anything we can do (about this bug) without changing the current syntax? Did you have a chance to see the cause of the bug? Does it only occur with the document structure as in my previous example?

  • Phred

    Phred December 5th, 2008 @ 11:07 AM

    This is an official opera bug with opera 9.x - bug #240407"). It is resolved with the release of Opera 10 alpha 1 however.

  • Xanadu

    Xanadu December 20th, 2008 @ 12:08 AM

    Today I encountered another/similar bug with $$ and Opera 9 (9.50+, can't remember the complete version number). My selector contained a class followed by an input with a type of checkbox.

    
    $$('.myClass input[type=checkbox]');
    

    I am not sure if this is a Prototype or an Opera bug and if it has the same cause.

  • Xanadu

    Xanadu December 20th, 2008 @ 12:10 AM

    The problem is the same, just 1 element is returned...

  • Juriy Zaytsev

    Juriy Zaytsev February 22nd, 2009 @ 11:47 PM

    • Tag changed from dom, opera, xpath to dom, needs_patch, needs_tests, opera, xpath
    • Title changed from “Opera & bug with $$()” to “Opera 9.x XPath descendants bug”

    As I understand it, the issue occurs when descendant selector is being evaluated via XPath. Does skipping XPath and falling back on manual iteration/collection sound reasonable?

    Too bad we need to cripple $$ so much due to a buggy implementation of such common selector : /

  • Juriy Zaytsev

    Juriy Zaytsev February 28th, 2009 @ 05:47 AM

    • Assigned user changed from “Juriy Zaytsev” to “Andrew Dupont”
    • Tag changed from dom, needs_patch, needs_tests, opera, xpath to dom, opera, patched, tested, xpath

    Attaching patch (based on feature detection at load time) and tests. Please, review.

  • GitHub Robot

    GitHub Robot February 28th, 2009 @ 11:42 AM

    • State changed from “bug” to “resolved”

    (from [26eaa4300b1fe088e394351bd882671e9561a290]) Fix issue where Opera 9.x returns incorrect results on certain Selector queries with descendant combinators. [#395 state:resolved] (Arpan, fearphage, kangax, Andrew Dupont) http://github.com/sstephenson/pr...

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 02:10 AM

    • Tag changed from dom, opera, patched, tested, xpath to opera, patched, section:dom

    [not-tagged:"dom" tagged:"section:dom" bulk edit command]

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 12:44 PM

    • Tag changed from opera, patched, section:dom to patched, section:dom

    [not-tagged:"opera" bulk edit command]

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

The Prototype JavaScript library.

Shared Ticket Bins

Attachments

Referenced by

Pages