Closed
Bug 836786
Opened 11 years ago
Closed 10 years ago
Mac OSX: Mouse over Flash mousemove event not occurring
Categories
(Core Graveyard :: Plug-ins, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla30
People
(Reporter: markp, Assigned: johns)
References
Details
(Keywords: regression)
Attachments
(1 file)
3.65 KB,
patch
|
jaas
:
review+
johns
:
checkin+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 Build ID: 20130116073211 Steps to reproduce: The jPlayer plugin detects the mousemove event over the video area to enable an auto-hide feature for the GUI. On MAC OSX 10.8.2 with Firefox 16 and Firefox 18 (versions tested) the mousemove event does not occur when the mouse is over the Flash area. When in full window mode, the user cannot get the GUI to display again since the mousemove event is not triggering its display. In my current development, the full screen API has the same problem when the flash is displayed full screen. (NB: This is through the W3C Full Screen API.) The Windows 7 version of Firefox does not have this problem. This problem has been reported on the jplayer google group. You can see the problem in action here. Select the full screen icon and the flash gets displayed in the full window view and the GUI no longer displays when the mouse is moved: http://www.jplayer.org/2.2.0/demo-01-video-solution-flash-html/ The following link is for comparison with the video in HTML5: http://www.jplayer.org/2.2.0/demo-01-video/ The following link shows the Flash not triggering mousemove event in the Full Screen mode: http://www.jplayer.org/2.2.15/demo-01-video-solution-flash-html/ That last link is temporary and will change to the following sometime in Feb 2013, if all goes to plan. http://www.jplayer.org/2.3.0/demo-01-video-solution-flash-html/ Actual results: The mousemove event does not occur when the mouse is moved over the flash area. Expected results: The mouse move event should have occurred when the mouse was moved over the flash area. This is what happens on Windows 7 Firefox and on every other windows and MAC browser tested... IE6/7/8/9, Chrome, Opera, Safari.
Reporter | ||
Comment 1•11 years ago
|
||
Posted this additional comment from the MAC and Firefox in question. I forgot that you grabbed the User Agent string... Hopefully you get it from this post.
Reporter | ||
Updated•11 years ago
|
OS: Windows 7 → Mac OS X
Reporter | ||
Comment 2•11 years ago
|
||
The User Agent on my mac: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20100101 Firefox/18.0
Comment 3•11 years ago
|
||
I get a html5 fullscreen dialog on OSX that I don't get on OSX
Status: UNCONFIRMED → NEW
Component: Untriaged → Plug-ins
Ever confirmed: true
Product: Firefox → Core
Comment 4•11 years ago
|
||
s/I don't get on OSX/I don't get on windows
Comment 5•11 years ago
|
||
I can reproduce this with a non-retina mac.
Keywords: regression,
regressionwindow-wanted
Priority: -- → P2
Comment 6•11 years ago
|
||
Odd that our event handling behaves differently in fullscreen mode ... if it does. I know (from tests I've done in the past with my Debug Events Plugin from bug 441880) that mousemoved events are sent correctly in non-fullscreen mode. Though I suppose it's a good idea to check that they still are. Too bad the Debug Events Plugin doesn't have a fullscreen mode. I should be able to get to this in the next few weeks, if nobody else beats me to it.
Comment 7•11 years ago
|
||
Last good nightly: 2011-08-09 First bad nightly: 2011-08-10 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=87e3ea12ed5d&tochange=04dfb49d3a3d maybe bug 665586 ? I could bisect this if required.
Comment 8•11 years ago
|
||
More likely: fee47b64b378 Markus Stange — Bug 675208 - Use NSTrackingArea for mouse event targeting. r=josh I suspect a bisection would help narrow this down.
Comment 9•11 years ago
|
||
I spoke too soon. That regression is too old to build with clang :-( I don't want to ruin my build system while trying to install gcc.
Comment 10•11 years ago
|
||
> I don't want to ruin my build system while trying to install gcc.
gcc comes with Apple's "Commandline Tools for XCode" downloads. Installing that shouldn't break your clang build system. In fact I suspect you already have it.
Comment 11•11 years ago
|
||
Actually we switched to clang on trunk when the patch for bug 733095 landed (on 2012-07-19). So you should be able to bisect using your clang build system.
Comment 12•11 years ago
|
||
I got this build error: http://pastebin.mozilla.org/2106177 After fixing gcc by symlinking gcc and g++ with the help of gfritsche i get this build error: http://pastebin.mozilla.org/2114076 Georg gets the same build error... >(on 2012-07-19) The regression range is in 2011
Comment 13•11 years ago
|
||
>> (on 2012-07-19)
> The regression range is in 2011
Oops, sorry :-(
Comment 14•11 years ago
|
||
As I said above, I'll get to this eventually. But first I'll need to construct a Lion VM with a sufficiently old version of XCode that its gcc works properly, and then create a build environment on top of that. (I've got a new MacPro running MountainLion, which should be powerful enough to host the VM without making its build times too slow.)
Comment 15•11 years ago
|
||
It's one of the patches for bug 665586 that triggered this bug: http://hg.mozilla.org/mozilla-central/rev/ec15be691f62 Bug 665586 Part 1: Kill AddEventListenerByIID/RemoveEventListenerByIID code from nsPluginInstanceOwner. r=josh author Jonas Sicking <jonas@sicking.cc> Mon Aug 08 11:26:22 2011 -0700 (at Mon Aug 08 11:26:22 2011 -0700)
Blocks: 665586
Comment 16•11 years ago
|
||
(Following up comment #14) Turns out XCode 4.1 for Lion is the last version that has a non-llvm gcc-4.2/g++-4.2, and a unified installer. Once I installed this on OS X 10.7.5, I was able to build old versions of Firefox with mozconfig files that once worked on OS X 10.6.8 (with those older versions of Firefox). Matthias, if you have a spare partition (or can run OS X 10.7.X in a virtual machine) you should consider creating a setup like this.
Updated•11 years ago
|
Priority: P2 → P3
Updated•11 years ago
|
Assignee: nobody → georg.fritzsche
Priority: P3 → P2
Updated•11 years ago
|
Keywords: regressionwindow-wanted
Comment 17•11 years ago
|
||
Hi, any updates on this? We in Yahoo! are also facing similar issues. Essentially, Firefox does not seem to fire mouse events within the area where the Flash player is rendered. This prevents us from capturing the Flash mouse-move event. Here are the OS details: Mac OSX Lion 10.7.5 Firefox version: 23.0.1 This issue does not happen on Windows FF
Comment 18•11 years ago
|
||
Sorry, i've not had a chance to look at this yet, but i'll see that i move it up my list. If anyone else wants to take a look though, i'd be happy to pass it on.
Comment 19•11 years ago
|
||
@gfritzsche, Any updates on this Flash mouse-move issue in Mac.
Comment 20•11 years ago
|
||
No updates yet, sorry. It's definitely gonna take a bit as i'll be away for a bit now and there are already other things lined up for afterwards.
Assignee | ||
Comment 21•11 years ago
|
||
(In reply to Steven Michaud from comment #15) > It's one of the patches for bug 665586 that triggered this bug: > > http://hg.mozilla.org/mozilla-central/rev/ec15be691f62 The issue here is that the mousemove handler used to call only PreventDefault() if the plugin returned EventHandled, but DispatchMouseToPlugin also calls StopPropagation, which stops other items on the page from consuming the event. DispatchMouseToPlugin also only calls PreventDefault for windowed plugins, without StopPropagation -- but in most cases we don't see the mouse events for windowed plugins anyway. Josh, do you know what we should be doing here? It seems like we should not be calling StopPropagation just because a plugin handles the event, but I don't understand most of the considerations in this code. We could just remove the StopPropagation() for mousemove to match our pre-regression behavior -- I'm guessing that many sites (erroneously?) depend on us stopping propagation of mouse clicks.
Flags: needinfo?(joshmoz)
Assignee | ||
Comment 22•11 years ago
|
||
Attachment #822540 -
Flags: review?(joshmoz)
Assignee | ||
Comment 23•11 years ago
|
||
Redundant needinfo w/r?, but see comment 21
Flags: needinfo?(joshmoz)
Assignee | ||
Comment 24•11 years ago
|
||
A build with the above patch is available here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jschoenick@mozilla.com-e1a9a35fbfae/try-macosx64-debug/ It would be helpful if someone experiencing this issue with their app could confirm that it produces the expected behavior
Attachment #822540 -
Flags: review?(joshmoz) → review+
Comment 25•10 years ago
|
||
Experiencing the same issue with video.js. https://github.com/videojs/video-js-swf/issues/37 @johns, I'm happy try this out. The above link appears to be broken now.
Assignee | ||
Comment 26•10 years ago
|
||
(In reply to Steve Heffernan from comment #25) > Experiencing the same issue with video.js. > https://github.com/videojs/video-js-swf/issues/37 > > @johns, I'm happy try this out. The above link appears to be broken now. Sorry, this dropped off my radar. That issue does sound like the same issue. I re-triggered the try build for this - if you could give it a shot and let me know if it behaves as you expect, I would be appreciative! http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jschoenick@mozilla.com-50cab73a053f/try-macosx64/
Assignee | ||
Comment 27•10 years ago
|
||
Comment on attachment 822540 [details] [diff] [review] Always allow plugin mousemove events to propagate for some reason https://hg.mozilla.org/integration/mozilla-inbound/rev/e8036c3e0a7b
Attachment #822540 -
Flags: checkin+
https://hg.mozilla.org/mozilla-central/rev/e8036c3e0a7b
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Comment 29•10 years ago
|
||
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Firefox/30.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101 Firefox/30.0 Verified as fixed on Firefox 30 beta 6, build ID: 20140520115057. Mouse over Flash mousemove event is now occurring and the GUI is displayed while in fullscreen mode.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Comment 30•9 years ago
|
||
in firefox 38.0.5 mac os doesnt fire mouseover event in flash object with javascript
Comment 31•9 years ago
|
||
(In reply to Carlos Navarrete from comment #30) > in firefox 38.0.5 mac os doesnt fire mouseover event in flash object with > javascript I think you can file a new bug with detailed steps on how you get this issue.
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•