RESOLVED CONFIGURATION CHANGED 25720
querySelectorAll do not consider hidden input field when querying for :enabled and :disabled pseudos 
https://bugs.webkit.org/show_bug.cgi?id=25720
Summary querySelectorAll do not consider hidden input field when querying for :enable...
Diego Perini
Reported 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
Attachments
Add attachment proposed patch, testcase, etc.
kangax
Comment 1 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>
Diego Perini
Comment 2 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.
kangax
Comment 3 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.
Diego Perini
Comment 4 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.
Ahmad Saleem
Comment 5 2022-07-22 11:25:01 PDT
All browsers pass WPT test for querySelectorAll - https://wpt.fyi/results/dom/nodes?label=master&label=experimental&aligned&q=queryselectorall Is this case covered via WPT tests? Thanks!
Alexey Proskuryakov
Comment 6 2022-07-22 16:16:58 PDT
I do not know about WPT, but browser appear to be aligned on the behavior now: <html> <body> <form> <input type="text"/> <input type="text" disabled="true"/> <input type="hidden"/> <input type="hidden" disabled="true"/> </form> <script> console.log(document.querySelectorAll(':enabled').length) console.log(document.querySelectorAll(':disabled').length) </script> </body> </html>
Note You need to log in before you can comment on or make changes to this bug.