251856 - {inc}CSS buttons move on mouseover

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Dennis Lynch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

In the page linked to this bug, the CSS buttons move when you mouseover, and
again when you mouseout.  When you mouseover/mouseout the buttons on the right
("Go 5" and "Go 6"), they move to the left. When you mouseover/mouseout the
buttons on the left ("Go 1", "Go 2" and "Go 3"), the buttons on the right ("Go
5" and "Go 6") move to the right.  The movement is less with each
mouseover/mouseout and eventually stops.  If the page is reloaded, the buttons
are back in place, but again they move when you mouseover/mouseout.

If you go back and forth across the left buttons, then the right, then the left,
etc, the movement seems to be only to the right, until the buttons on the right
add an implied line-feed to their text.

Reproducible: Always
Steps to Reproduce:
1. Load the page
2. Mouseover/mouseout one of the CSS buttons on the right
3. Continue until the movement stops
4. Reload and try again with the buttons on the left.
4. Reload and try again, moving the mouse back and forth across the buttons on
the left and the right.
Actual Results:  
The buttons changed size, the buttons on the right moved, and the table cells
changed sizes.

Expected Results:  
Buttons should not move, or change size, and table cells should not change size.

As you might guess, these buttons were part of a much larger page.  I stripped
out everything I could and retested to ensure the problem still occurred as I
removed HTML and JS code from the file.  The HTML file I have linked here is
about the minimum that reproduces the bug.  When I remove the center TD in the
table the problem does not recur, but this will not satisfy my content needs.

I did see somewhat similar bugs in the Bugzilla database, though they weren't
completely similar- bug # 167425 (which is pretty old yet still open) and #
175455 (which says it is resolved, yet I still have the problem).

Comment 1

[Martin Alderson]

Confirmed here.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This needs a minimal testcase, and is probably a duplicate of an existing
incremental reflow bug....

Comment 3

[dolphinling]

Attachment: A more (but not completely) simplified testcase

Didn't have time to finish this right now, but here's a more simplified
testcase.

Comment 4

[Hermann Schwab]

Attachment: more minimized testcase

a,a:link,a:visited { border: 2px solid #ff00ff;}
a:hover,a:active {border-width:3px;}

making the border-widths even doesn´t show the bug.

Comment 5

[Hermann Schwab]

(In reply to comment #4)
> Created an attachment (id=153601)

> a,a:link,a:visited { border: 2px solid #ff00ff;}
> a:hover,a:active {border-width:3px;}
> 
> making the border-widths even doesn´t show the bug.

making the border-widths EQUAL doesn´t show the bug,
sorry I`m not a native speaker ;-)

Comment 6

[Dennis Lynch]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6)
Gecko/20040113
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6)
Gecko/20040113
> 
> In the page linked to this bug, the CSS buttons move when you mouseover, and
> again when you mouseout.  When you mouseover/mouseout the buttons on the right
> ("Go 5" and "Go 6"), they move to the left. When you mouseover/mouseout the
> buttons on the left ("Go 1", "Go 2" and "Go 3"), the buttons on the right ("Go
> 5" and "Go 6") move to the right.  The movement is less with each
> mouseover/mouseout and eventually stops.  If the page is reloaded, the buttons
> are back in place, but again they move when you mouseover/mouseout.
> 
> If you go back and forth across the left buttons, then the right, then the left,
> etc, the movement seems to be only to the right, until the buttons on the right
> add an implied line-feed to their text.
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. Load the page
> 2. Mouseover/mouseout one of the CSS buttons on the right
> 3. Continue until the movement stops
> 4. Reload and try again with the buttons on the left.
> 4. Reload and try again, moving the mouse back and forth across the buttons on
> the left and the right.
> Actual Results:  
> The buttons changed size, the buttons on the right moved, and the table cells
> changed sizes.
> 
> Expected Results:  
> Buttons should not move, or change size, and table cells should not change size.
> 
> As you might guess, these buttons were part of a much larger page.  I stripped
> out everything I could and retested to ensure the problem still occurred as I
> removed HTML and JS code from the file.  The HTML file I have linked here is
> about the minimum that reproduces the bug.  When I remove the center TD in the
> table the problem does not recur, but this will not satisfy my content needs.
> 
> I did see somewhat similar bugs in the Bugzilla database, though they weren't
> completely similar- bug # 167425 (which is pretty old yet still open) and #
> 175455 (which says it is resolved, yet I still have the problem).

Comment 7

[Dennis Lynch]

...Sorry about that last comment added to the database...
... here's what I meant to say:

The comment from Hermann Schwab is indeed accurate.. but does not recognize the
UI design/intent.

The design of the UI is intended to give the appearance of a button going down
on each rollover. The styles in the original example were (simplified here for
clarity):
 .menu a:link {border-width:1px 2px 2px 1px;}
 .menu a:hover {border-width:2px 1px 1px 2px;}

With these styles, each time the mouse hovers over one of these links the top
and left borders will increase by 1px (and the text would move right and down by
1px as a result).  The bottom and right borders shrink by 1px to absorb the
expansion.  Thus, the appearance of downward movement of the button is created.

In my opinion, the bug remains.  Further, avoiding the bug by not changing the
border sizes does not meet the UI design objectives.

Comment 8

[Dennis Lynch]

It seems this bug has "languished", and has somehow been put as "unconfirmed". 
But, I have demonstrated the bug, and would like to make sure the bug remains on
some list to be fixed.

I'm sorry if I do not know all the protocols and procedures for handling bugs...
I just don't want this bug to be swept aside.

Thank you.

Comment 9

[Jesiah S]

Hermann's responce was not meant to tell you to not change the width and close
this bug.  It was meant to inform the next person working on this bug what seems
to be the problem.
If you want a workaround define the width of the cells or define the LIs using
px or something similar.

Comment 10

[Gervase Markham [:gerv]]

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 11

[Steve England [:stevee]]

Both testcase behaviour changes between:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a (pre-reflow branch)
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 (post-reflow branch)
But I can't say if the new behaviour is expected or desired.

Comment 12

[Mats Palmgren (inactive)]

Attachment: Testcase with reference tables

Comment 13

[Mats Palmgren (inactive)]

New behaviour looks correct to me, when hovering the pink borders changes
to 3px and the table layout adapts correctly to that (see the reference
tables in the 3rd attachment) - and when unhovered the layout is changed back
to the original layout. SeaMonkey 2006120801 (post reflow branch) on Linux.

-> FIXED (by the reflow branch landing)