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

RESOLVED FIXED in mozilla1.7alpha

Status

()

Core
Layout: Floats
P2
minor
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: Erich Schubert, Assigned: dbaron)

Tracking

({testcase})

Trunk
mozilla1.7alpha
x86
Linux
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch])

Attachments

(4 attachments)

(Reporter)

Description

14 years ago
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

Comment 1

14 years ago
Created attachment 138148 [details]
testcase

Updated

14 years ago
Keywords: testcase

Updated

14 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: DUPEME
(Assignee)

Comment 2

14 years ago
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.
(Assignee)

Comment 3

14 years ago
Created attachment 140837 [details] [diff] [review]
possible patch

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

Updated

14 years ago
Assignee: core.layout.floats → dbaron
Status: NEW → ASSIGNED
(Assignee)

Updated

14 years ago
Priority: -- → P2
Whiteboard: [patch]
Target Milestone: --- → mozilla1.7alpha
(Assignee)

Comment 4

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

Comment 5

14 years ago
(and a bunch of similar tests)
(Assignee)

Comment 6

14 years ago
Created attachment 140879 [details]
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.
(Assignee)

Comment 7

14 years ago
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)
(Assignee)

Comment 8

14 years ago
Created attachment 140880 [details]
simple testcase for what's broken
(Assignee)

Updated

14 years ago
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+
(Assignee)

Comment 10

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

Filed bug 233480.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

14 years ago
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.
(Assignee)

Updated

13 years ago
Depends on: 237366
You need to log in before you can comment on or make changes to this bug.