Closed Bug 349004 Opened 14 years ago Closed 12 years ago
Table information is displayed diferently after refresh
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20060728 Firefox/220.127.116.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20060728 Firefox/22.214.171.124 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.
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.
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
Component: General → Layout
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
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:126.96.36.199) Gecko/20060728 Firefox/188.8.131.52
Is this a problem with reflow branch builds?
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.
Reproducable in Fx2, but not in Fx3 and higher.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Sounds like reflow branch in fact fixed this, then. Could use a testcase.
Depends on: reflow-refactor
Resolution: WORKSFORME → FIXED
(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.
Attachment #238416 - Attachment is obsolete: true
(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.
Oh, I wasn't talking about a reduced testcase. I was talking about a reftest (and typo-ed, but set the flags correctly).
(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.
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.
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.
As a reporter of this bug I'm happy that it doesn't reproduce on Firefox 3. Thanks!
(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.
You need to log in before you can comment on or make changes to this bug.