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)

x86
Windows XP
defect
Not set
normal

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 ;-)
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" />
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/
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.