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

Status: RESOLVED INCOMPLETE

(Core :: Web Painting, defect)

Description

[Martijn Wargers (dead)]

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

[Shane]

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

[Simon Porter]

I am not sure the regression window but 2.0.0.4 has this problem.

Comment 3

[Karl Tomlinson (:karlt)]

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

[Martin Heidegger]

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

[kaldari]

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 2.0.0.11 for Windows XP.

Comment 6

[Martijn Wargers (dead)]

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

[kaldari]

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

[kaldari]

Attachment: testcase for overflow:auto and wmode opaque

Comment 9

[kaldari]

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.

Comment 10

[Jerry Su]

Here is another test case for what I believe to be the same bug:
http://jsu07.com/random/ffwinflashoverflow.html

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

Comment 11

[Shane]

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

[Jerry Su]

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.
http://jsu07.com/random/ffwinflashoverflowfix.html

Comment 13

[u597032]

Flash is no longer supported