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)

18 Branch
x86_64
macOS
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla30

People

(Reporter: markp, Assigned: johns)

References

Details

(Keywords: regression)

Attachments

(1 file)

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.
OS: Windows 7 → Mac OS X
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.
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 <jonas@sicking.cc>
	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.
Priority: P2 → P3
Assignee: nobody → georg.fritzsche
Priority: P3 → P2
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.
Flags: needinfo?(joshmoz)
Redundant needinfo w/r?, but see comment 21
Flags: needinfo?(joshmoz)
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
Assignee: georg.fritzsche → jschoenick
Attachment #822540 - Flags: review?(joshmoz) → review+
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://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jschoenick@mozilla.com-50cab73a053f/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+
https://hg.mozilla.org/mozilla-central/rev/e8036c3e0a7b
Status: NEW → RESOLVED
Closed: 10 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
Keywords: verifyme
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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: