309056 - {inc}Empty space remains after leaving a:hover with padding-bottom

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect)

Description

[Marat Tanalin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Some hovered links with padding-bottom for hover pseudoelement has empty space
at bottom instead of saving element background color on entire element area and
simply add padding-bottom. See the testcase.

Reproducible: Always

Steps to Reproduce:
1. Make table with fixed height (200px for example) and one table cell.
2. Make one more table that is nested into table cell of table created before.
3. Put links (<a href="#">...</a>) to the cells of the nested table.
4. Set CSS-background for A element and padding-bottom for A:hover pseudoelement.
5. Move the cursor over (through several items) created navigation menu from
right to left and from left to right.
OR see the testcase.

Actual Results:  
On hovering links (menu items) you will periodically see _empty_ visual space
under menu items instead of padding space filled with the element background color.

Expected Results:  
Padding space of the pseudoelement must be simply filled with the same
background the element has. No any empty space must appear.

It’s interesting that some items of menu is not subjected to this problem, and
such specific items are _differ_ on each loading of the page.

Comment 1

[Marat Tanalin]

Additional info: this problem only appears in versions from Deep Park Alpha 1
(and maybe early nightlies) to Firefox 1.5 Beta 1 released on 2005-09-09. There
is no this problem in Firefox 1.06.

Comment 2

[Mats Palmgren (inactive)]

Regression window: 2004-08-09-05 -- 2004-08-10-06
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-08-09+04%3A00&maxdate=2004-08-10+08%3A00&cvsroot=%2Fcvsroot
bug 230170 perhaps?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: More minimal testcase

Comment 4

[Boris Zbarsky [:bzbarsky]]

The async style stuff could be exposing it, but it seems the problem is that if
the table's height doesn't change we don't really redo the vertical alignment
here.  Not sure how the floating is relevant here, btw, but it is...  The top
padding I only left because it makes the bug easier to reproduce.

Comment 5

[Marat Tanalin]

As I see, this bug doesn’t appears anymore in latest trunk builds (2006-12-08, 2006-12-14, 2006-12-21), evidently thanks to Reflow branch landed on 2006-12-07.
So, the bug is apparently fixed (as probably many other bugs too). Reflow branch = good branch.