Bug Tracker

Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#8474 closed bug (patchwelcome)

[ firefox] jquery >= 1.5 won't work with flowplayer tooltip

Reported by: anonymous Owned by: dmethvin
Priority: high Milestone: 1.next
Component: event Version: 1.5.1
Keywords: Cc:
Blocked by: Blocking:


Someone asked to post a sample here,


full discussion: http://flowplayer.org/tools/forum/30/58627

Change History (11)

comment:1 Changed 12 years ago by dmethvin

Owner: set to anonymous
Status: newpending

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.


comment:2 Changed 12 years ago by anonymous

Status: pendingnew

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.

comment:3 Changed 12 years ago by dmethvin

Component: unfiledevent
Milestone: 1.next1.5.2
Owner: changed from anonymous to dmethvin
Priority: undecidedblocker
Status: newassigned

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

comment:4 Changed 12 years ago by anonymous

I have the same problem

comment:5 Changed 12 years ago by dmethvin

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)

Last edited 12 years ago by dmethvin (previous) (diff)

comment:6 Changed 12 years ago by john

Priority: blockerlow

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

comment:7 Changed 12 years ago by anonymous

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.


comment:8 Changed 12 years ago by john

Milestone: 1.5.21.next
Priority: lowhigh

comment:9 Changed 12 years ago by anonymous

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:10 Changed 12 years ago by dmethvin

Resolution: patchwelcome
Status: assignedclosed

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.

comment:11 Changed 12 years ago by anonymous

Maybe just revert the behaviour for FireFox?

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

Note: See TracTickets for help on using tickets.