Wrong mouse coordinates for windowless mode flash object with position:absolute and overflow:scroll or overflow:auto




Layout: View Rendering
11 years ago
8 months ago


(Reporter: Martijn Wargers (dead), Unassigned)



Windows XP

Firefox Tracking Flags

(Not tracked)




(1 attachment)



11 years ago
This was a testcase that was attached in bug 248054, comment 16.

There is still a bug in current branch and trunk builds where the mouse is 'off' when hovering over certain flash objects with wmode=transparent and some absolute positioning scheme and overflow:scroll.

Comment 1

11 years ago
This problem was fixed before version 2 of Firefox even came out.  I am very confused as to why the problem is back.  I get what I believe is the same issue here: http://www.libbeygroup.com/  In this case, there is some obnoxious flickering.

Comment 2

11 years ago
I am not sure the regression window but has this problem.
bug 248054, comment 19 I think describes the problem:
"since Firefox receives mouse events relative
to window the mouse is over, and a scrolling DIV means a new window. They are
being translated relative to the window the flash is in"...

I suspect we could change adjust the mouse coordinates to be relative to the same window that we tell the plugin about in nsPluginInstanceOwner::GetValue for NPNVnetscapeWindow.

Comment 4

11 years ago
I am able to confirm this still. Its enough to have just one div with overflow:hidden/auto. In my test it works with wmode=opaque as well.

Comment 5

10 years ago
I can also confirm that this bug is not restricted to wmode=transparent and overflow:scroll. Overflow:auto triggers it just as well, and the Flash object doesn't have to be wmode=transparent. Someone needs to edit the title of this bug to make it more accurate. Here is an example of the bug in the wild: http://www.cmt.com/pictures/2007-cmt-music-awards-arrivals-gallery-1/1557271/2415135/photo.jhtml (see the Fructis billboard ad in the sidebar which is completely non-functional). It should be noted that this bug only affects Firefox on Windows, not Firefox on Mac. How is the Macintosh implementation different? That may provide a clue to solve the problem.

Confirmed in Firefox for Windows XP.

Comment 6

10 years ago
This bug is about trunk builds (which is what Firefox 3 will be made of, currently).
It's not really useful to test with Firefox 2 anymore, regarding this bug.

Comment 7

10 years ago
I have confirmed this bug in Firefox 3.0b5 on Windows Vista using the testcase. Interestingly, it looks like bug 248054 may NOT be a duplicate of this bug since I couldn't reproduce bug 248054 in Firefox on Vista at all (only on XP). I'll try to do some more investigation.

Comment 8

10 years ago
Created attachment 316014 [details]
testcase for overflow:auto and wmode opaque

Comment 9

10 years ago
Nevermind, after creating the new testcase I was able to confirm both cases on XP and Vista. The new testcase I've attached shows the bug using overflow:auto and wmode set to opaque. So the bug seems to effect any windowless mode flash (opaque and transparent are the two variations of "windowless") and overflow set to scroll or auto.


10 years ago
Summary: Wrong mouse coordinates for wmode=transparent flash object with position:absolute and overflow:scroll → Wrong mouse coordinates for windowless mode flash object with position:absolute and overflow:scroll or overflow:auto

Comment 10

9 years ago
Here is another test case for what I believe to be the same bug:

Has anyone come across a workaround that doesn't involve setting wmode="window" and allows overflow to be auto or scroll?

Comment 11

9 years ago
I was able to correct this issue by simply adding html { margin: 1px; } to the css. It may not be the most ideal solution, but a solution nonetheless.

Comment 12

9 years ago
Thanks for your suggestion Shane.  I wasn't able to get html{margin:1px;} to work on my test case.  However, I did come up with a solution using another DIV with overflow:auto as a shim and positioning this at (0,0). It involves a bit of JS to show/hide the shim, which is OK for my implementation.
QA Contact: ian → layout.view-rendering
Assignee: roc → nobody


8 months ago
Last Resolved: 8 months ago
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → ---
You need to log in before you can comment on or make changes to this bug.