349004 - Table information is displayed diferently after refresh

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Cristian Iorga]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

The table information is displayed diferently after refresh even thou the html code doesn't change. Can be tested with the saved page open offline.

Reproducible: Always

Steps to Reproduce:
1. Close all you Firefox windows
2. Open Firefox
3. http://gpro.be/Stats.asp?type=bestcars
4. Refresh

Actual Results:  
The table information is displayed diferently after page refresh

Expected Results:  
The table should look the same after refresh.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060816 BonEcho/2.0b1
The page looks the same here, before and after the reload. Please empty your cache and try again.

Comment 2

[Mats Palmgren (inactive)]

I can reproduce it in SeaMonkey trunk and Firefox 2.0b1 on Linux.
The ranking table becomes slightly wider on Reload.
A minimal testcase would help...
http://wiki.mozilla.org/MozillaQualityAssurance:Triage

Comment 3

[Cristian Iorga]

The bug reproduces ONLY if prior to opening the link you close all firefor windows. The first page accesed by the Firefox when you open it again must be the mentioned link. 

My information : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

Comment 4

[Boris Zbarsky [:bzbarsky]]

Is this a problem with reflow branch builds?

Comment 5

[Martijn Wargers (dead)]

Attachment: stats-page attached to the bug

I couldn't find the page directly, the direct link to the page gives a redirect, so I'm attaching it to the bug.

(In reply to comment #4)
> Is this a problem with reflow branch builds?

It seems fixed with the reflow branch build, the ranking table doesn't become slightly wider anymore on reload, it always stays as wide as it is, with the reflow branch build.

Comment 6

[Daniel.S]

Reproducable in Fx2, but not in Fx3 and higher.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Sounds like reflow branch in fact fixed this, then.  Could use a testcase.

Comment 8

[Daniel.S]

Attachment: partially reduced testcase

(In reply to comment #7)
> Sounds like reflow branch in fact fixed this, then.  Could use a testcase.

Phew, I can't get any further than this. Even removing seemingly useless class attributes seems to be a remedy.

Well, the bug is that Gecko 1.8.1 sometimes ignored the width set on the third cell of the header row ("Group", 65px). Gecko 1.9 always keeps this width.

Comment 9

[Daniel.S]

(In reply to comment #8)
> Created an attachment (id=354552) [details]
> partially reduced testcase

Ctrl + F5 ten times, and it should be misrendered about a third of the time (in Firefox 2).

Well, that's true for my local copy, but doesn't seem to work while refreshing the attachment, sigh.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Oh, I wasn't talking about a reduced testcase.  I was talking about a reftest (and typo-ed, but set the flags correctly).

Comment 11

[Daniel.S]

(In reply to comment #10)
> Oh, I wasn't talking about a reduced testcase.  I was talking about a reftest
> (and typo-ed, but set the flags correctly).

"Testcase for a fixed bug" sounded awkward to me anyway, so I intended to do a small reftest for practice, but didn't quite figure out just how to do that. The bug occurs rather randomly.
Maybe someone else can help out with the bit of information, what the bug actually is.

Comment 12

[dolphinling]

The bug was that (prior to reflow branch landing) during incremental rendering, gecko would load part of the document, display it, load the rest of the document, and then omit crucial parts of the "display the rest" step, specifically things like recomputing some table cell widths.

All the bugs like this (there were many individual bugs, all fixed by bug 300030) were sporadic because they depended on which part of the document was rendered when--and that depended on things like the speed of your internet connection, how fast and how loaded your CPU was, whether the OS decided to give CPU time to the network stack or the application, the phase of the moon, etc.

I'm not sure how one would make an automated test for this--are we even sure the reftest harness won't cause extra reflows, making the bug disappear? The best bet might be to take the original or anything close to it that *always* displays the bug, and then find something that *never* displays it with as few modifications as possible. bz might have other ideas.

Comment 13

[Martijn Wargers (dead)]

Attachment: testcase

I managed to get it reduced to this.
I think both tables should look the same in this case.

In this case, I could notice the reflow bug quite easily, when I compared the unminimized testcases with normal reload and shift->reload.

Comment 14

[Cristian Iorga]

As a reporter of this bug I'm happy that it doesn't reproduce on Firefox 3. Thanks!

Comment 15

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

(In reply to comment #12)
> 300030) were sporadic because they depended on which part of the document was
> rendered when--and that depended on things like the speed of your internet

That dependency can be handled by putting something like:

<script> var x = document.body.offsetTop; </script>

at an appropriate point in the middle of the document, since that forces a layout to happen given exactly the content before the script.