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)
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
Comment 1•19 years ago
|
||
Rossi, is this bug 311622?
Comment 2•19 years ago
|
||
(In reply to comment #1)
> Rossi, is this bug 311622?
Nevermind, I doubt it is, sorry for the 2 spams.
Comment 3•19 years ago
|
||
I've tried the testcase with my debug build which has the fix for bug 271442. It seems fixed with that.
Depends on: 271442
Comment 4•19 years ago
|
||
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
Comment 6•18 years ago
|
||
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.
Comment 7•18 years ago
|
||
Anyway, this bug was fixed by the patch for bug 271442.
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•