fixed block moves after :hover on subblock ends




15 years ago
14 years ago


(Reporter: spam_from_bugzilla, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)



15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)

I have a footer block that is {position: fixed; bottom: 0; height: 3ex}.  It
contains sub-blocks that should "pop up" when moused over, i.e. they are
normally {position: absolute; bottom: 0; height: 3ex} so just their top portion
is visible but also have :hover {height: auto}.

Everything works until the hover ends.  At this point the popup "retracts", but
the body of the footer also moves down.  I will attach a demo.

Possibly related bugs are #207915 and #225419.  This may be a dupe of one of
them, but it is hard to see what is going on (this may be a simpler test case).
 No-one seems to be working on either of those.

Reproducible: Always

Steps to Reproduce:

Comment 1

15 years ago
Posted file Test case


15 years ago
Attachment #172122 - Attachment mime type: text/plain → text/html

Comment 2

15 years ago
I see the bug with firefox 1.0, but seamonkey trunk 2005012205 works fine.
please try a trunk build (1.8a6)

Comment 3

15 years ago

Great news - thanks.  Would you like to have a look at bugs #207915 and #225419
and see if either of them has also been fixed?

The width of the red block seems to be inconsistent, though.

Comment 5

15 years ago
Moving in/out of the blue box fast makes the red block flicker at the top of the
blue box occasionally (2005-01-22-05 Linux).

Comment 6

15 years ago
Yes, this does seem to be better in 1.8b.  I'd still consider the flicker to be
a minor bug though.  On a more complex page it looks poor.
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:

Comment 8

14 years ago
(In reply to comment #7)
> This bug has had no comments for a long time.

I don't have spare time available to download a current build at the moment. 

- It would be very easy for someone who already has a current build to check it
by viewing the attached test case. 

- Perhaps it should have been confirmed when comments 4 and 5 were added, and so
escaped this auto-resolution.

Comment 9

14 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051210 Firefox/1.6a1

Works for me. Reopen if you can reproduce in the latest builds.
Closed: 14 years ago
Resolution: --- → WORKSFORME

Comment 10

14 years ago
(In reply to comment #9)
> Works for me. Reopen if you can reproduce in the latest builds.

Alan, thanks for checking on this.  I don't have a current build but I do have the latest Debian package (what they call 1.4.99+1.5rc3.dfsg-2) and it displays the problem in its original form as in comment #1.  This seems to be a regression from the 1.8b (Mozilla suite) that I downloaded and noted in comment #6.

Are you aware of any changes since FF 1.5rc3 that might have improved things?


Comment 11

14 years ago
s/Alan/Adam/g.  Sorry, it's late...

Comment 12

14 years ago
Phil, I don't. If I did I would've duped this bug to that one. :( The fix also could have been something that was checked into trunk but not branch.

Comment 13

14 years ago
Definitely fixed now in today's nightly build.
You need to log in before you can comment on or make changes to this bug.