Closed Bug 645305 Opened 9 years ago Closed 4 years ago

Problem with jQuery.isDefaultPrevented(), jquery >= 1.5


(Firefox :: General, defect)

Not set



Tracking Status
platform-rel --- -


(Reporter: yuri.pimenov, Unassigned)


(Keywords: testcase, Whiteboard: parity-ie parity-webkit [bugday-20110401] [platform-rel-jQuery])

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0

There is a problem which shows itself with jquerytools tooltip module and recent jquery 1.5 on FF.

In brief, event.getPreventDefault() always returns True for some events. 

Reproducible: Always
Testcases from the jquery bug report, for reference:

Did this work in Firefox 3.6.x?
Component: General → DOM: Events
Keywords: testcase
Product: Firefox → Core
QA Contact: general → events
Version: unspecified → Trunk
> Did this work in Firefox 3.6.x?

No, based on that first testcase.

Looks like for mouse enter/exit events something sets aEventStatus to nsEventStatus_eConsumeNoDefault while dispatching to the nsGlobalChromeWindow.  I have no idea what that something is, but I really doubt this is a Gecko issue.

In fact, I don't think this is a bug at all; just some listener is calling preventDefault() on the event...
Component: DOM: Events → General
Product: Core → Firefox
QA Contact: events → general
Not sure about those test cases - but this worked fine for me in FF 3.6.x and now everything is broken in FF 4.0 under the exact same conditions.
Scott, could you find the regression range please - might be the quickest way of finding out what is going on. This tool bisects, so can find the range fairly quickly:
My bad - I just found out someone here changed jQuery 1.5 to 1.5.1 and I didn't know - seems it's not working in FF 3.6 after all.

(that mozregression is a cool tool though - so glad to learn about it)
Dunno, if it helps but all major browsers output (false,false) in the first testcase. Only firefox outputs (true,undefined).
For the first element of the pair, again, there's just a listener calling preventDefault.

For the second, we don't implement that particular IE-ism.  Given that everyone else does, sounds like we'll need to at some point.  :(
Component: General → DOM: Events
Ever confirmed: true
OS: Windows 7 → All
Product: Firefox → Core
QA Contact: general → events
Hardware: x86 → All
Whiteboard: parity-ie parity-webkit [bugday-20110401]
Ryan, this bug was in the right place.  See comment 2.
Component: DOM: Events → General
Ever confirmed: false
Product: Core → Firefox
QA Contact: events → general
Oh, and I'm setting it back to UNCO because it needs triage within Firefox, and a NEW in General will just get lost, I suspect.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.2a1pre) Gecko/20110401 Firefox/4.2a1pre


Definitely reproducible -- does that make this NEW? Normally it would, but I'm not so sure given comment 9.
> undefined:

This is correct behavior, as far as it goes.  We don't implement that IE-ism yet.
Whiteboard: parity-ie parity-webkit [bugday-20110401] → parity-ie parity-webkit [bugday-20110401] [platform-rel-jQuery]
platform-rel: --- → ?
If I update to the latest 1.x release of jQuery, this works as expected now:

(we get false, false just like Chrome)
Closed: 4 years ago
platform-rel: ? → -
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.