Closed Bug 318108 Opened 19 years ago Closed 18 years ago

wrong mouse coordinates for flash movie with wmode transparent and position fixed

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: rossi, Unassigned)

References

()

Details

when a flash movie is inside an element with fixed position AND the wmode is set to transparent, the mouse coordinates inside the flash movie are messed up. so i don't know if this is a bug in the plugin itself or the way mozilla handles it. in opera, the same thing works fine. (internet explorer doesn't have fixed position, so...). also it works in non-transparent wmode, and also when the position is absolute, but not fixed.
the problem with this is, that all buttons inside a flash movie stop working, because the coordinates aren't right.
the testcase:
the flash movie just outputs its mouse x and y coordinates. when you switch the wmode (i have to do this via innerHTML because it doesn't work on the fly) you can see that it doesn't start with 0 any more but with -100, the negative of the left position)
my version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051128 Firefox/1.6a1
(In reply to comment #1)
> Rossi, is this bug 311622?

Nevermind, I doubt it is, sorry for the 2 spams.
I've tried the testcase with my debug build which has the fix for bug 271442. It seems fixed with that.
Depends on: 271442
Sorry, comment 3 was meant for a different bug.
Actually, this bug is workforme, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060719 SeaMonkey/1.5a
No longer depends on: 271442
There is a *bug* with the newest version of Mozilla (Firefox ver 1.5.0.6) which I just downloaded and installed today.

This is a Mozilla bug--not Firefox

When I use CSS "position: fixed -or- position: absolute" to position my Flash movie, the Flash button "hotspots" are offset from where they are defined in the Flash movie. This also only happens when the Flash movie 'wmode' is set to 'transparent'.

The button rollover offset is right of the actual button, the distance varies and is greater--the larger the window is than the Flash movie. I'm using position fixed to center the movie in the browser window.

Examples:

Without absolute or fixed positioning:  http://www.satarah.com/clients/demo/nopos.html
(no bugs evident since not using fixed positioning)

With CSS fixed positioning:  http://www.satarah.com/clients/demo/pos.html
(rollover bug evident on Firefox ver 1.5.0.6)


This is only the case with the most recent version of Mozilla (Firefox ver 1.5.0.6) (that I know of).

Everything works in the version I just updated from (Firefox ver 1.0.7) and all other browsers I have tested this in (Opera, Safari, IE-Win, Netscape -- various versions of each).

I built the Flash movie in Flash 5, and have FlashPlayer 8.0.22.0 plugin for Firefox. I also scrubbed my Flash movie source to make certain the problem is not somehow being generated on my end.

When I don't "fixed" or "absolute" position the movie, the button hotspots are exactly where they are supposed to be.

I have tried various efforts to work around this problem, including: using <object> and/or <embed> to wrap the movie, wrapping the movie in a <div> element and positioning the <div> instead, dynamically writing the Flash and/or CSS with javascript using DOM methods, etc...

I created two no-frills html pages to illustrate the problem I'm describing, so if you want to take a look and 'view-source' on them you can do so here:

Without absolute or fixed positioning:  http://www.satarah.com/clients/demo/nopos.html
(no bugs evident since not using fixed positioning)

With CSS fixed positioning:  http://www.satarah.com/clients/demo/pos.html
(rollover bug evident on Firefox ver 1.5.0.6)



Thank you for any help or advice,


Kevin Douglas
kdouglas@satarah.com
September 5th, 2006
Kevin, thanks for mentioning this bug and making such a fine testcase. However, it is better to file this as a seperate bug, since this one is already fixed by 271442, which is on the 1.8.1 branch (which is where Firefox2 is coming from).
I filed bug 351535 for the bug you mentioned in comment 5.
Anyway, this bug was fixed by the patch for bug 271442.
Status: NEW → RESOLVED
Closed: 18 years ago
Depends on: 271442
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.