Skip to main content

Bug Tracker

Side navigation

#8474 closed bug (patchwelcome)

Opened March 08, 2011 06:35PM UTC

Closed May 09, 2011 02:09PM UTC

Last modified March 14, 2012 06:12PM UTC

[ 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:
Description

Someone asked to post a sample here,

http://jsfiddle.net/WFjgd/3/

full discussion:

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

Attachments (0)
Change History (11)

Changed March 09, 2011 01:48AM UTC by dmethvin comment:1

owner: → 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.

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

Changed March 09, 2011 10:39AM UTC by anonymous comment:2

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.

Changed March 10, 2011 03:27PM UTC by dmethvin comment:3

component: unfiledevent
milestone: 1.next1.5.2
owner: anonymousdmethvin
priority: undecidedblocker
status: newassigned

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

Changed March 16, 2011 08:47AM UTC by anonymous comment:4

I have the same problem

Changed March 22, 2011 03:54AM UTC by dmethvin comment:5

_comment0: 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) \ 1300991221704651

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)

Changed March 25, 2011 12:01AM UTC by john comment:6

priority: blockerlow

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

Changed April 06, 2011 06:01AM UTC by anonymous comment:7

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/

Changed April 17, 2011 08:19PM UTC by john comment:8

milestone: 1.5.21.next
priority: lowhigh

Changed April 18, 2011 07:54PM UTC by anonymous comment:9

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;

Changed May 09, 2011 02:09PM UTC by dmethvin comment:10

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.

Changed May 13, 2011 02:40PM UTC by anonymous comment:11

Maybe just revert the behaviour for FireFox?

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