It was me, and I asked:

However, we'd need a simple test case (preferably in jsfiddle.net) that showed the problem and did not include the whole plugin.

This looks like it includes the whole plugin, which I don't want to debug. :(

Can you post an example of the problem without the plugin, or at least debug it a bit further?

Based on this thread by Kelvin Luck, which tried to repro it without the plugin and failed, I suspect the problem is the plugin's attempt to fire a second event by reusing an existing one.

http://forum.jquery.com/topic/jquery1-5-isdefaultprevented-always-return-true-in-firefox-for-some-events

Not sure if I did it correctly, but here http://jsfiddle.net/Qq6uW/16/ you can see that on firefox it returns undefined while on chrome it's false.

hope it helps, my skills are finished here on debugging this bug.

Thanks! That is a nice small test case, so I'll take a look.

I have the same problem

Further update, the original Firefox mouseover event returns getPreventDefault() == true. So our Event object refects that. Any other input on this bug welcome.

http://jsfiddle.net/dmethvin/Qq6uW/20/ (Firefox only)

Edit: This version shows jQuery is not a factor:

http://jsfiddle.net/dmethvin/Qq6uW/24/ (Firefox only)

At the very least, this is no longer a blocker (based upon Dave's feedback).

I created a test case to show that this is really a bug of jQuery 1.5/1.5.1

Run the below case with jQuery 1.5 or 1.5.1 in firefox, the isDefaultPrevented() is always TRUE.

If run the case with jQuery 1.4.4, isDefaultPrevented() is FALSE which is correct.

http://jsfiddle.net/Qq6uW/35/

I would like to add that Opera 9.27 (Presto 2.0) has a "bug" that causes isDefaultPrevented to always return TRUE:

event objects always have "returnValue" and

"returnValue" always returns false, even if it

was just assigned true

setting returnValue to false works properly as

default action prevention

I used this pseudocode as bug detection:

event.returnValue = true;

presto_2_0_bug = !event.returnValue;

Comment 9, we only support the last two versions of Opera (10.63 and the most recent 11) so Opera 9 wouldn't factor into a fix.

Comment 7, jQuery 1.4 did not correctly copy the defaultPrevented state (it was ALWAYS false initially even if an earlier handler had called .preventDefault) so that's why it appears to work there. If you look at the test case in comment 5 that doesn't even include jQuery you can see that Firefox is incorrectly showing the defaultPrevented.

Bottom line, this is a Firefox bug. If anyone has a way for us to determine when Firefox is lying about defaultPrevented we might be able to work around this.

Maybe just revert the behaviour for FireFox?

(when browser == FF) => defaultPrevented is always false