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.
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.
The User Agent on my mac: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20100101 Firefox/18.0
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
s/I don't get on OSX/I don't get on windows
I can reproduce this with a non-retina mac.
Keywords: regression, regressionwindow-wanted
Priority: -- → P2
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.
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.
More likely: fee47b64b378 Markus Stange — Bug 675208 - Use NSTrackingArea for mouse event targeting. r=josh I suspect a bisection would help narrow this down.
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.
> 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.
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.
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
>> (on 2012-07-19) > The regression range is in 2011 Oops, sorry :-(
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.)
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 <email@example.com> Mon Aug 08 11:26:22 2011 -0700 (at Mon Aug 08 11:26:22 2011 -0700)
(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.
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
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.
@gfritzsche, Any updates on this Flash mouse-move issue in Mac.
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.
(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.
Redundant needinfo w/r?, but see comment 21
A build with the above patch is available here: http://firstname.lastname@example.org/try-macosx64-debug/ It would be helpful if someone experiencing this issue with their app could confirm that it produces the expected behavior
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.
(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://email@example.com/try-macosx64/
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+
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
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
You need to log in before you can comment on or make changes to this bug.