Closed Bug 229654 Opened 20 years ago Closed 20 years ago

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

Categories

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

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla1.7alpha

People

(Reporter: erich, Assigned: dbaron)

References

Details

(Keywords: testcase, Whiteboard: [patch])

Attachments

(4 files)

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.
Summary: When a hover has a different bottom-border with, an "auto margin" grows with the hover trigger → {inc}When a hover has a different bottom-border with, an "auto margin" grows with the hover trigger
Whiteboard: DUPEME
Attached file testcase
Keywords: testcase
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: DUPEME
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.
Attached patch possible patchSplinter Review
This fixes the bug.  All but the first bit is cleanup.	I still need to run
regression tests, but it seems right.
Assignee: core.layout.floats → dbaron
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: [patch]
Target Milestone: --- → mozilla1.7alpha
(and a bunch of similar tests)
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 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.
Attachment #140879 - Attachment description: simple testcase for what's broken → variant of simple testcase for what's broken (with display:block on root)
Attachment #140837 - Flags: superreview?(bzbarsky)
Attachment #140837 - Flags: review?(bzbarsky)
Comment on attachment 140837 [details] [diff] [review]
possible patch

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

r+sr=bzbarsky
Attachment #140837 - Flags: superreview?(bzbarsky)
Attachment #140837 - Flags: superreview+
Attachment #140837 - Flags: review?(bzbarsky)
Attachment #140837 - Flags: review+
Fix checked in to trunk, 2004-02-08 21:22 -0800.

Filed bug 233480.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Depends on: 237366
You need to log in before you can comment on or make changes to this bug.