229654 - {inc}When a hover has a different bottom-border with, an "auto margin" grows with the hover trigger

Status: RESOLVED FIXED

(Core :: Layout: Floats, defect, P2)

Description

[Erich]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Galeon/1.3.11a (Debian package 1.3.11a-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 (Galeon, Firebird both show it)

The page consists of a <div> floated left (so it hasn't a width specified but is
not 100% either). Inside the <div> there is another div with an "auto" margin.
When the mouse triggers the hover effect of a link which only changes the
border-bottom width, the auto margin grows.

Reproducible: Always

Steps to Reproduce:
1. On the page, move the mouse over the link
2. repeat

Actual Results:  
the box grew needless upon displaying the hover effect and doesn't shrink back
afterwards. Repeatedly triggering the hover will make the box grow further.

Expected Results:  
No change in box width.

Comment 1

[Anne (:annevk)]

Attachment: testcase

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The problem has to do with BRS_SHRINKWRAPWIDTH -- we're applying the auto
margin, and then doing a second reflow in nsBlockFrame::ComputeFinalSize using
the kid X-most, which means the kid's width plus half the space available for
margins.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: possible patch

This fixes the bug.  All but the first bit is cleanup.	I still need to run
regression tests, but it seems right.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The only thing this seems to break is
http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/xml/tests/css3-modsel-28.xml

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(and a bunch of similar tests)

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: variant of simple testcase for what's broken (with display:block on root)

Adding <?xml-stylesheet href="data:text/css,test { display: block; }"
type="text/css"?> to the beginning of this page fixes the problem.  I'm
inclined to check this in and file a separate bug on the regression, since I'm
sure we have other problems with inline root elements caused by the same
underlying problem.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 140879 [details]
variant of simple testcase for what's broken (with display:block on root)

Oops, this was the wrong testcase.  Note also that an intervening
display:inline element doesn't break things since we do block-within-inline
splitting.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: simple testcase for what's broken

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 140837 [details] [diff] [review]
possible patch

seems reasonable.  Do file a followup on the ib stuff, though.

r+sr=bzbarsky

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to trunk, 2004-02-08 21:22 -0800.

Filed bug 233480.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Note to self: my checkin comment for this bug was (I think) wrong when I said
that there's still a bug remaining for max-width computation during constrained
reflow.  nsBlockReflowContext::PlaceBlock already handles that issue.