29413 - [MARGIN-C]{inc} margins get lost on inc reflow if 'clear' is not none [FLOAT]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Nathaniel Turner]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; N; NT4.0; en-US) Mozilla/m13
BuildID:    2000022408

When a link that has an a:visited style is clicked on, a paragraph above it that
has clear:left and margin-top:3m loses it's margin-top style and "jumps up" to
have a top margin of 1em (default).

Reproducible: Always
Steps to Reproduce:
1. Go to http://beast.res.wpi.net/~testcases/textjump.html
2. Follow the directions on that page



I have a lot of pages with clear:left set on the h1 and h2 tags.  This is a
common style to set; it makes sure headings are flush left, not wrapped around
some floating image from the previous paragraph.  Because h1 and h2 have top
margins (of more than 1em) by default, ANY pages like this will jump around when
ANY of their links are clicked on.  This is not just a cosmetic bug, because
links that jump out of your way when you click on them cause a serious usability
problem.

I set the severity (perhaps controversially) to major because
a) the ability to follow hyperlinks quickly is a major
   feature (practically *the* most major feature in a web
   browser)
b) it's broken on any pages with clear:left set on their
   h1,h2, or h3 tags

Comment 1

[sarnold]

Using my Linux CVS build (afternoon of February 26th) I was only able to
reproduce this bug with method number 3 -- using "tab" to select the link. The
other two methods did not do wierd things.

I am using nsViewManager2 and the gfx widgets.

Comment 2

[Alan S. Jones]

Ok, I looked at this bug and could reproduce all 3 cases on Win95 with 2/27/00  
-08 build.  My guss is parser or layout type bug.

[e-mail] It is generally recomended that the developers or QA set the 
severity level.

Comment 3

[rickg]

I don't have the cycles to triage this properly, but I'm seeing the bug. It 
looks like a style problem, so over to mark for triage.

Comment 4

[Marc Attinasi]

I'll learn what Style is doing here.

Comment 5

[Marc Attinasi]

The URL is forbidden - can we attach it as a testacase?

Comment 6

[Marc Attinasi]

Attachment: Testcase showing the bug.

Comment 7

[Marc Attinasi]

I attached a testcase.

This looks like a layout issue. The style rule will cause the link to get an 
outline, which is causing an incremental reflow (a known bug) but then the 
paragraphs are laying out incorrectly.

If you remove the 'clear:left' style rule from the paragraph then the problem 
does not occur. Also, 'clear:right' causes the same behavior.

Comment 8

[troy]

Floater related. Looks like "clear" around floater is causing a problem

Comment 9

[buster]

Important to fix, but low priority for beta2.  Moving to M18.

Comment 10

[buster]

redistributing bugs across future milestones, sorry for the spam

Comment 11

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

Retitling - previous title confused me every time I saw it, because I thought
the bug was invalid because clear is defined to expand the margin-top...

Comment 12

[Hixie (not reading bugmail)]

Note: Host in URL is unreachable. Since I just made a testcase for this trying 
to find what the problem was, I'll attach it.

This bug makes it difficult to use hover effects with floats, which is quite a
common occurance in CSS based pages. Nominating nsbeta3.

Comment 13

[Hixie (not reading bugmail)]

Attachment: Yet another testcase.

Comment 14

[Marc Attinasi]

Denying approval for beta3: too many bugs and not enough resources, so this one 
will have to be atteneded to in the future.

Comment 15

[Hixie (not reading bugmail)]

David: Do your margin fixes change this? There is a difference in the way
top margins of 'clear'ed elements are calculated when a full reflow is done
as opposed to an incremental reflow (the incremental reflow gets it wrong).

Reassigning to David for him to briefly look at this. It _sounds_ like an 
easy enough fix, but based on his recent comments it probably is not...

Comment 16

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

Another margin collapsing bug for buster.

Comment 17

[buster]

P3, so Future

Comment 18

[buster]

P3 bugs are getting moved to "future" milestone.  They will not be addressed for
NS6 RTM.

Comment 19

[Hixie (not reading bugmail)]

My testcase no longer shows the bug, however Marc's is still valid.

Comment 20

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 21

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

There was a bit of code that wasn't succeeding in doing anything that I removed
from nsBlockReflowState::RecoverStateFrom in the patch for bug 86947 that
mentioned this bug (and said that if the code were working, it would have fixed
this bug).

Comment 22

[Greg K.]

WorksForMe using FizzillaCFM/2002070913. Neither testcase exhibits the described
behavior.

Comment 23

[Hixie (not reading bugmail)]

yeah, this works for me too now (both my testcase and marc's).

Comment 24

[Adam Hauner]

Marking FIXED regarding last WFM comments and David's comment #21.

Comment 25

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

I think a better resolution would be worksforme, since we don't know what fixed
it.  (My comment said I removed the code that would have fixed it, not added it.)

Comment 26

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

worksforme.