bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Flash plugin within a css transformed div does not handle mouse position properly

RESOLVED FIXED in mozilla1.9.3a5



8 years ago
6 years ago


(Reporter: Luc Devallonné, Assigned: mats)



Mac OS X
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(status1.9.2 ?)




(5 attachments, 2 obsolete attachments)



8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/ Safari/532.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100105 Firefox/3.6

It seems that the mouse position send to the Flash plugin does not take into account the css transformed.

Reproducible: Always

Steps to Reproduce:
1.go to http://uniboard-misc.s3.amazonaws.com/plugin_transform.html
2.start movie
3.try to change movie position by clicking on the slider => does not work

Actual Results:  
The movie does not change position

Expected Results:  
The movie change position

If you click around 2/3 of the height of the movie, you can grab the position slider.

looks like the css scale transform of 1.5 is not applied to the mouse coordinates sent to the Flash plugin
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2pre) Gecko/20100113 Namoroka/3.6pre

Maybe related to Bug 538989. 
It is indeed not easy to grab the slider with the mouse.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Version: unspecified → 1.9.2 Branch

Comment 2

8 years ago
Bug 538989 is related to a windowed plugin, but in this case it is in windowsless mode

The content is properly display, just the mouse event are not transformed back to the plugin native coordinates

Comment 3

8 years ago
I have observed this bug for a long time since at least Firefox 2.0 and frankly I'm amazed it's still there in 3.6 (only on the Mac).

Here are some other observations I can add. It seems that FF can get into a state in which this misalignment of detected and real mouse position occurs. When in this state the misalignment occurs, however when FF is not in this state there is no misalignment. One place where I observe this A LOT is hulu.com with their video player.

Another significant observation is I have found a way to put FF back from the "misaligning state" into the working state. This is done by resizing FF. When I observe this misalignment I resize FF by moving the bottom right corner just a bit. This causes the entire window to jump! This is important. I think it is jumping by the amount of the misalignment between detected and real mouse position. Once in the working state, resizing no longer causes the window to jump and there is no more misalignment, i.e. flash works as designed.

The fact that the window jumps leads me to believe this is really a FF issue, not a flash issue. I know there's always the suspicion that it might be the others, i.e. flashs, fault.

I feel this bug is so significant that it makes me look for alternatives. This deserves some attention!

Comment 4

8 years ago
For windows, FF already have a workaround; it translates events to flash as is but it informs flash about its' actual size.

For Mac, we can recompute events like this:

--- old/nsObjectFrame.cpp   2010-02-09 19:55:29.664159200 +0200
+++ new/nsObjectFrame.cpp   2010-02-18 19:35:33.314640800 +0200
@@ -484,10 +484,16 @@
     return "";
+  // VK: just servant function in one line
+  PRBool IsShockwaveFlash()
+  {
+    return MatchPluginName("Shockwave Flash");
+  }
   PRBool SendNativeEvents()
 #ifdef XP_WIN
-    return MatchPluginName("Shockwave Flash");
+    return IsShockwaveFlash();
     return PR_FALSE;
@@ -4437,6 +4453,22 @@
+      // VK: adjust mouse pointer position for flash plug-in if transformed 
+        if (anEvent.eventStructType == NS_MOUSE_EVENT && IsShockwaveFlash()) { 
+           nsPoint pt = nsLayoutUtils::GetEventCoordinatesRelativeTo(&anEvent, mOwner)
+             - mOwner->GetUsedBorderAndPadding().TopLeft();
+           nsPresContext* presContext = mOwner->PresContext();
+           nsIntPoint ptPx(presContext->AppUnitsToDevPixels(pt.x),
+                        presContext->AppUnitsToDevPixels(pt.y));
+           EventRecord* er = (EventRecord*)anEvent.nativeMsg;
+           nsIntPoint scw = mWidget->WidgetToScreenOffset();
+           Point carbonPt = { ptPx.y + scw.y, ptPx.x + scw.x };
+           if(er) {
+             if (er->where.h != carbonPt.h || er->where.v != carbonPt.v) 
+               er->where = carbonPt;
+           }
+         }
       PRBool eventHandled = PR_FALSE;
       WindowRef window = FixUpPluginWindow(ePluginPaintEnable);
       if (window) {

Comment 5

8 years ago
Created attachment 427610 [details] [diff] [review]
Recompute mouse pointer coords to current transform for flash plug-in, MacOS X only


8 years ago
Attachment #427610 - Flags: review?(matspal)

Comment 6

8 years ago
Comment on attachment 427610 [details] [diff] [review]
Recompute mouse pointer coords to current transform for flash plug-in, MacOS X only

Your calculation of the coordinate looks good, but there are
a couple of things I'd like to change.  First, I don't see
any reason to only do this for Flash; second, we already have
essentially this code on lines 4417 -- 4422:
I think it would be better to fix that code and
just calculate the coordinate once.
Attachment #427610 - Flags: review?(matspal)

Comment 7

8 years ago
Created attachment 428854 [details] [diff] [review]
Victor's patch with my suggested changes [for 1.9.2]

Victor, this is what I suggested above, does this look
right to you?
Attachment #427610 - Attachment is obsolete: true
Attachment #428854 - Flags: review?(vik)


8 years ago
Keywords: pp


8 years ago
Ever confirmed: true

Comment 8

8 years ago
Sorry for long delay; yes, this way is much better. Thank  you very much.


8 years ago
Attachment #428854 - Flags: review?(vik) → review?(roc)
Comment on attachment 428854 [details] [diff] [review]
Victor's patch with my suggested changes [for 1.9.2]

We should add a test for this to the Mac test plugin.
Attachment #428854 - Flags: review?(roc) → review+


8 years ago
Attachment #428854 - Attachment description: Victor's patch with my suggested changes → Victor's patch with my suggested changes [for 1.9.2]

Comment 10

8 years ago
Created attachment 431009 [details] [diff] [review]
Additional fix for testplugin on OSX [for 1.9.2]

Indeed.  After writing said test it revealed a bug in the
testplugin on OSX.  This patch just copies what is trunk
is already doing.
Assignee: nobody → matspal
Attachment #431009 - Flags: review?(joshmoz)


8 years ago
Version: 1.9.2 Branch → unspecified

Comment 11

8 years ago
Created attachment 431011 [details] [diff] [review]
OSX fix for trunk

This is roughly what roc already reviewed above.  Can you check
that I got those NP_NO_CARBON/NPEventModelCarbon bits right please?
Attachment #431011 - Flags: review?(joshmoz)

Comment 12

8 years ago
Created attachment 431012 [details] [diff] [review]

Test mouse click coordinate with a few combinations of fullZoom
and transform:scale.  Sorry for slicing up the tests with
setTimeout(..., 0) but I couldn't make it pass reliably otherwise.
(something about zooming is async?)
Suggestions for improvements appreciated.

Comment 13

8 years ago
Haven't tested much on Windows yet, but the mochitest failed on m-c TryServer.
All tests seems to work on Linux (m-c and 1.9.2).

Comment 14

8 years ago
The test actually fails also on OSX with the attached fixes:
  fullZoom=2 MozTransform='' - got 271, expected 272
  fullZoom=2 MozTransform='scale(0.5)' - got 542, expected 544
which looks like a result of pixel rounding.
I think we should go ahead with the patches as is (unless someone
see something obviously wrong with them) and I'll make the test
tolerate the deviance above.  We can fix the pixel rounding later
in a separate bug.

Comment 15

8 years ago
Created attachment 432140 [details]

Comment 16

8 years ago
Created attachment 432141 [details] [diff] [review]
mochitest v2
Attachment #431012 - Attachment is obsolete: true

Comment 17

8 years ago
On Windows trunk, the mouse event coordinate is correct but Flash
ignores the event if it's outside the non-transformed boundaries.
(STR: load the attached Testcase, Zoom-, set X-origin=1500px)
It works fine for the x-test plugin, and I debugged it for Flash
down to the point where we invoke the plugin event handler and
everything looks good to that point, so I suspect a bug in Flash
on Windows (it works on Linux and OSX).


8 years ago
Attachment #431011 - Flags: review?(joshmoz)
Attachment #431011 - Flags: review?
Attachment #431011 - Flags: review+

Comment 18

8 years ago
Comment on attachment 431011 [details] [diff] [review]
OSX fix for trunk

I'll review the 1.9.2 patch after this has been on trunk for a few days.
Attachment #431011 - Flags: review?


8 years ago
Attachment #431009 - Flags: review?(joshmoz)

Comment 19

8 years ago
Comment on attachment 431009 [details] [diff] [review]
Additional fix for testplugin on OSX [for 1.9.2]

+ifndef __LP64__

There is no 64-bit support on 1.9.2 so you don't need this.
Attachment #431009 - Flags: review+

Comment 20

8 years ago

Filed bug 562068 on the Flash plugin for ignoring some mouse clicks on Windows.
Last Resolved: 8 years ago
status1.9.2: --- → ?
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
Version: unspecified → Trunk
Depends on: 562626
Depends on: 722222
You need to log in before you can comment on or make changes to this bug.