Mac OSX: Mouse over Flash mousemove event not occurring

VERIFIED FIXED in mozilla30



6 years ago
4 years ago


(Reporter: markp, Assigned: johns)



18 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)



6 years ago
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:

The following link is for comparison with the video in HTML5:

The following link shows the Flash not triggering mousemove event in the Full Screen mode:

That last link is temporary and will change to the following sometime in Feb 2013, if all goes to plan.

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.

Comment 1

6 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.


6 years ago
OS: Windows 7 → Mac OS X

Comment 2

6 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
I get a html5 fullscreen dialog on OSX that I don't get on OSX
Component: Untriaged → Plug-ins
Ever confirmed: true
Product: Firefox → Core
s/I don't get on OSX/I don't get on windows

Comment 5

6 years ago
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


maybe bug 665586 ?
I could bisect this if required.

Comment 8

6 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.
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:
After fixing gcc by symlinking gcc and g++ with the help of gfritsche i get this build error:
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:

 Bug 665586 Part 1: Kill AddEventListenerByIID/RemoveEventListenerByIID code from nsPluginInstanceOwner. r=josh
author	Jonas Sicking <>
	Mon Aug 08 11:26:22 2011 -0700 (at Mon Aug 08 11:26:22 2011 -0700)
Blocks: 665586
(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.


6 years ago
Priority: P2 → P3


6 years ago
Assignee: nobody → georg.fritzsche
Priority: P3 → P2
Keywords: regressionwindow-wanted

Comment 17

6 years ago
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.

Comment 19

6 years ago
@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.

Comment 21

6 years ago
(In reply to Steven Michaud from comment #15)
> It's one of the patches for bug 665586 that triggered this bug:

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)

Comment 23

6 years ago
Redundant needinfo w/r?, but see comment 21
Flags: needinfo?(joshmoz)

Comment 24

6 years ago
A build with the above patch is available here:

It would be helpful if someone experiencing this issue with their app could confirm that it produces the expected behavior


5 years ago
Assignee: georg.fritzsche → jschoenick


5 years ago
Attachment #822540 - Flags: review?(joshmoz) → review+

Comment 25

5 years ago
Experiencing the same issue with video.js.

@johns, I'm happy try this out. The above link appears to be broken now.

Comment 26

5 years ago
(In reply to Steve Heffernan from comment #25)
> Experiencing the same issue with video.js.
> @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!

Comment 27

5 years ago
Comment on attachment 822540 [details] [diff] [review]
Always allow plugin mousemove events to propagate for some reason
Attachment #822540 - Flags: checkin+
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Keywords: verifyme
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.
Keywords: verifyme

Comment 30

4 years ago
in firefox 38.0.5 mac os doesnt fire mouseover event in flash object with javascript
(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.
You need to log in before you can comment on or make changes to this bug.