Bug 25720 - querySelectorAll do not consider hidden input field when querying for :enabled and :disabled pseudos
Summary: querySelectorAll do not consider hidden input field when querying for :enable...
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-12 02:40 PDT by Diego Perini
Modified: 2009-05-28 04:36 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Perini 2009-05-12 02:40:43 PDT
Tested on www.google.com main page in the URL bar:

javascript:alert(document.querySelectorAll(':enabled').length);

returned result set length is 10 in FF 3.5, while in Safari 3/4 the returned result set length is 7. Three hidden input fields are missing from the returned result set.

Related specifications:

http://www.w3.org/TR/css3-selectors/#UIstates
Comment 1 kangax 2009-05-14 05:44:54 PDT
I actually get "4" (in alert) on <http://www.google.com/> when using nightly build (r43663), but yes, input[type=hidden] doesn't seem to be part of returned NodeList.

It looks like WebKit is following HTML5 draft here, which says that :enabled should *not match* input elements with type=hidden <http://www.w3.org/TR/html5/interactive-elements.html#selector-enabled>
Comment 2 Diego Perini 2009-05-27 10:53:55 PDT
(In reply to comment #1)
> I actually get "4" (in alert) on <http://www.google.com/> when using nightly
> build (r43663), but yes, input[type=hidden] doesn't seem to be part of returned
> NodeList.
> 
> It looks like WebKit is following HTML5 draft here, which says that :enabled
> should *not match* input elements with type=hidden
> <http://www.w3.org/TR/html5/interactive-elements.html#selector-enabled>
> 

The problem was I typed "www.google.com" but I was redirected to "www.google.it" where I did executed the test and I erroneously reported a wrong testing URL.
Comment 3 kangax 2009-05-27 12:16:29 PDT
Diego,

I assume FF3.5 follows CSS Selectors specs, rather than HTML5 ones. I'm not sure if FF actually prefers former one, or if this issue was just never raised, but we should still file a bug; 

Having to work around different implementations (i.e. in Mozilla and WebKit) is not very pleasant.
Comment 4 Diego Perini 2009-05-28 04:36:25 PDT
Ok kangax,
I submitted bug #495217 to Mozilla bug tracking here:

https://bugzilla.mozilla.org/show_bug.cgi?id=495217

Let see if devs can equalize their current implementations, or if there are other comments/reasons that we didn't consider.

As I said in the Mozilla bug report it seems to me there will be advantages in to following HTML5 specification for "UI element states" pseudo-classes.