Closed
Bug 264038
Opened 20 years ago
Closed 19 years ago
Button Hit areas of Flash Components are shifted if placed in div position:fixed
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
EXPIRED
People
(Reporter: fspitzka, Assigned: bugzilla)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
If a Flash Component(<object><embed> etc...) is placed inside a <div> with
position:fixed the hitareas of buttons become offset by double. If the fixed div
is placed at x:0 y:0 everything is fine, but if the div is placed at e.g. x:10
y:10 the hitareas will be doubled to x:20y:20. if the fixed div is at x:150y:150
the hitareas will be shifted to x:300y:300 from the top left of the document
etc... all other elements in the flash file are where they should be, even the
images on buttons (up over down states are where they should be) just the
'invisible' hit area layer is shifted by double of the fixed div coordinate.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Expected Results:
hitareas should be aligned with Flash buttons within fixed dives regardes of
coordinate of the fixed div.
i was able to come up with a workaround by putting a relative div with the flash
code inside a fixed div positioned at x:0y:0. this will however not work with
with positioning from the right or bottom edge of the document. (e.g. right:0px;
and/or bottom:0px;)
i was not able to recreate this problem on a macintosh version of firefox.
ie, even though there is not support for div fixed, gets around this problem by
using css expressions. would be nice to see that in firefox ;-)
Reporter | ||
Comment 1•20 years ago
|
||
This issue ONLY occures if wmode is set to transparent, which allows flash to be
superimposed onto the document with a transparent background
<param name="wmode" value="transparent" />
Reporter | ||
Comment 2•20 years ago
|
||
Comment 3•19 years ago
|
||
This is an automated message, with ID "auto-resolve01".
This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.
While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.
If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.
The latest beta releases can be obtained from:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/
Comment 4•19 years ago
|
||
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•