Skip to main content

Bug Tracker

Side navigation

#7719 closed bug (worksforme)

Opened December 07, 2010 10:53AM UTC

Closed April 17, 2011 09:15PM UTC

:disabled has bugs in Opera

Reported by: MrMamen Owned by: browser-opera
Priority: high Milestone: 1.6
Component: selector Version: 1.4.4
Keywords: browserbug browser-opera Cc: miketaylr
Blocked by: Blocking:

var fields = $('
      <input type="input" disabled="disabled">
      <input type="input" disabled="true">

Expected result is "2". Actual result is "0" in Opera 10.63 and 11 beta. Other browsers work.

This bug was introduced in 1.4.3 but is still present in 1.4.4

Attachments (0)
Change History (14)

Changed December 07, 2010 11:38AM UTC by MrMamen comment:1

The input fields should state "type='text'", but the error is the same.

Changed December 07, 2010 11:00PM UTC by jitter comment:2

cc: → miketaylr
priority: undecidedhigh
status: newopen

Thanks for taking the time to contribute to the jQuery project by writing a bug report. The code you posted has several issues (type="input" and disabled="true" both are invalid values and the inputs are not self closed) but this all doesn't matter, as the issue remains even after fixing these.

After some initial tests to investigate what is going on it looks like this is a bug in Opera (maybe the qSA implementation), but I'm not sure yet.

I made a few different test cases:\\\\

reproduction of reporters code\\\\

some working tests\\\\

test case partially failing (1.4.2!)

These tests tell us:

  • the bug isn't related to the jQuery version (happens in 1.3.x and 1.4.x)
  • the bug is related to qSA and only happens in Opera
  • the bug only happens for specific code and html

The reason you discovered this only with jQuery 1.4.3+ is related to an internal code change (since 1.4.3 qSA is used for Element-rooted queries too).

More investigation is needed on this one. Bringing in our Opera expert on this one.

Changed December 14, 2010 04:59PM UTC by jitter comment:3

Mike did you have time/interest to look at this one?

Changed December 14, 2010 05:00PM UTC by anonymous comment:4

Sorry, time no--interest yes. Last week was consumed by AddOnCon. I'll take some time this week to dig in.

Changed December 14, 2010 05:00PM UTC by miketaylr comment:5

Oops, that was me.

Changed January 24, 2011 05:10PM UTC by miketaylr comment:6

Yikes, 6 weeks has gone by. I've got some bandwidth today to do some investigating.

Changed January 24, 2011 07:30PM UTC by miketaylr comment:7

A few things to note before I forget...

See which alert()s 1 in Opera, 3 elsewhere. Compare that with which alert()s 3.

I'm messing with tests here too:

Changed January 24, 2011 08:55PM UTC by miketaylr comment:8

It just dawned on me, Sizzle's ":disabled" doesn't really use qSA, right? If you update the test to actually use QSA, it seems OK:

@jitter, thoughts?

Changed February 01, 2011 09:32AM UTC by MrMamen comment:9

This bug is still present in Opera 11.01, and jQuery 1.5. Is the conclusion that this is an Opera bug?

Changed February 02, 2011 08:20PM UTC by anonymous comment:10

That it still happens in 11.01 isn't surprising--that release was essentially a security fix. Still not quite sure where the problem is, but like I mentioned in my previous comment, if you don't use ":disabled" it works.

Changed February 15, 2011 09:15PM UTC by miketaylr comment:11

I can confirm this as an Opera NodeSelector bug. CORE-36571 has been reported on our end. We treat dyanamically created (and disabled) elements as not :disabled.

Changed February 16, 2011 01:35AM UTC by jitter comment:12

component: unfiledselector
keywords: → browserbug
owner: → browser-opera
status: openassigned

Changed April 13, 2011 11:05AM UTC by MrMamen comment:13

This seems to have been fixed in Opera 11.1.

Changed April 17, 2011 09:15PM UTC by john comment:14

keywords: browserbugbrowserbug browser-opera
resolution: → worksforme
status: assignedclosed

Oooh, fixed in a current version of Opera - that's good enough for me!