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

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.

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. nturner@wpi.edu It is generally recomended that the developers or QA set the severity level.

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.

I'll learn what Style is doing here.

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

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.

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

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

redistributing bugs across future milestones, sorry for the spam

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...

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.

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

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...

Another margin collapsing bug for buster.

P3, so Future

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

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

Build reassigning Buster's bugs to Marc.

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).

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

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

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

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.)

worksforme.