#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: |
Description
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
Owner: | set to anonymous |
---|---|
Status: | new → pending |
comment:2 Changed 12 years ago by
Status: | pending → new |
---|
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
Component: | unfiled → event |
---|---|
Milestone: | 1.next → 1.5.2 |
Owner: | changed from anonymous to dmethvin |
Priority: | undecided → blocker |
Status: | new → assigned |
Thanks! That is a nice small test case, so I'll take a look.
comment:5 Changed 12 years ago by
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)
comment:6 Changed 12 years ago by
Priority: | blocker → low |
---|
At the very least, this is no longer a blocker (based upon Dave's feedback).
comment:7 Changed 12 years ago by
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
Milestone: | 1.5.2 → 1.next |
---|---|
Priority: | low → high |
comment:9 Changed 12 years ago by
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
Resolution: | → patchwelcome |
---|---|
Status: | assigned → closed |
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
Maybe just revert the behaviour for FireFox?
It was me, and I asked:
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