Closed Bug 217004 Opened 21 years ago Closed 21 years ago

sometimes table renderes wrong depending on time the script needs

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: flo, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718

You get a correct output if the script doesn't stop output: Try this with
http://bier.homeip.net/leftcolbug/leftcolbug.php?sleep=0
Then try sleep=1 or higher, and try to reload and SHIFT-reload. Sometimes the
center column of the main table is shifted to the right.

Interesting: I've commented some HTML in the source. If you delete it, the bug
cannot be reproduced. You can get the source (including the sleep() line) here:
http://bier.homeip.net/leftcolbug/leftcolbug.phps

Reproducible: Sometimes

Steps to Reproduce:
1. see above
2.
3.

Actual Results:  
see above

Expected Results:  
not shift the middle column sometimes

IE works O.K. mozilla-firebird and older mozill versions have this bug too
I can confirm this bug, running Windows XP and Mozilla Firebird 0.6.1.

To reproduce the table rendering bug, I must increase the sleep value by a lot.
 If you can't reproduce, try sleep values of 5, 8, 10, 15, 20, etc.
http://bier.homeip.net/leftcolbug/leftcolbug.php?sleep=5
http://bier.homeip.net/leftcolbug/leftcolbug.php?sleep=10
http://bier.homeip.net/leftcolbug/leftcolbug.php?sleep=15
http://bier.homeip.net/leftcolbug/leftcolbug.php?sleep=20
I cant reproduce the problem with 2003-08-1515 reporter could you please
download a recent nightly and test again.
Tested with Build ID: 2003082222 Linux. Shifted column appears. Sometimes you
have to go to higher sleep values and you have to shift-reload the page - try
sleep=8, then reload, then shift-reload or similar.
We are developing a php based CMS and if we do performance tests, mozilla shows
this bug on almost every page. All HTML validators validate our html/css output
without errors.

Thank you,

Flo 
Now tested with compiled source: If bug shows, i get two lines:
WARNING: empty damage rect: update caller to avoid fcn call overhead, file
nsFrame.cpp, line 2551
and after the sleep time i get some more of them. If the bug doesn't show, i get
all these lines after the sleep time.
poked around in source. Seems that in nsBlockFrame.cpp line 2438 Invalidate() is
called with wrong size.

Another conclusion i had: If you press reload and don't move the mouse pointer,
the bug will not show, If you press reload and try to move the mouse where the
left menu of the web page will show, the bug shows (tested a few times and it's
almost 100% reproducable). Seems that teedog (comment 2 of this bugreport)
doesn't move his mouse very much :-)

Thank you,

Flo
I can confirm that moving your mouse around after reloading causes the bug to
surface every time, even using sleep=1.
I can confirm on WinXP with Firebird nightly 20030914 and on Linux with Mozilla
1.4.  Problem does not seem to occur in Opera 7.11 or IE 6.0.
I can confirm that moving your mouse around after reloading causes the bug to
surface every time, even using sleep=0.
This is a serious pain in the ass when I write perfectly legit/wc3 compliant
code and it doesn't rnder correctly!
CC
Blocks: 200047
This problem has occurred for me in the CMS Drupal's admin section, so it's
definately not a bug exclusive to TikiWiki, which all the examples so far have
come from.

For me, the bug manifests whenever I leave the mouse cursor on the menu (whether
moving it or not), but immediately goes away when moving the mouse cursor off
the menu.  (This is when reloading the exact same page.)  No example URL yet...
sorry -- it's only occurred on administration pages for me

Could this be related to bug 215857 somehow?
This is the same problem as http://bugzilla.mozilla.org/show_bug.cgi?id=153771 ,
which was marked "resolved WORKSFORME" due to inadequate testing by the resolvers.

The bug still appears intermittently on http://www.ukcycling.net/, DESPITE a
forced page rebuild, with all recent release.

This is a TIME-SENSITIVE bug. IF you are on a fast link and/or the server is not
heavily loaded, you will not see it. The bug only appears when the time taken to
receive the page is long and specific timing conditions occur within the browser.
WORKSFORME,
Mozilla nightly trunk build 2003-12-12-09 on Linux
Mozilla nightly trunk build 2003-12-12-09 on Windows 98 SE
(Most likely fixed by bug 215857)
(See also bug 217590 comment 25)
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Problem still occurs intermittently for me with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031212
Firebird/0.7+
http://tikiwiki.org/ frequently exhibits the bug as well.
I disagree with marking this bug RESOLVED and hope someone with appropriate
permissions will reopen it.
.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
-> Tables
Assignee: roc → table
Status: REOPENED → NEW
Component: Layout: View Rendering → Layout: Tables
HAPPENSFORME -- all the time dudes.  All the time.

http://tikiwiki.org

Firebird .7+
I get this bug frequently. It's making (the otherwise excellent) TikiWiki barely
usable 80% of the time, and it has also made some eCommerce sites look a
complete mess. This is true with Mozilla 1.2-1.6 on Windows 98, XP and RedHat 9.0.

The speed of the connection isn't important in my experience either. This occurs
on my LAN - it even occurs when its being served on localhost.

I think this needs serious investigation. We don't want a world class browser
being spoilt by nasty formating errors.
What this bug needs in order to be investigated is a simplified testcase.

Furthermore, it's worth noting that there are many URLs mentioned here and no
evidence that it's really the same bug.  So the simplified testcase for this bug
should be simplified from the URL in comment 0.  Some of the other URLs may be
different problems.
I'm not using Firebird or Mozilla until this is fixed.  So long.
Does anyone still see the bug on the URLs in comment 0 and comment 1?  If so,
could you describe Actual Results and Expected Results more clearly?
(And for those of you discussing other sites than the ones in comment 0 and
comment 1 in this bug, you're offtopic, and probably making this bug much more
confusing than it should be, unless you demonstrate using a simplified testcase
that it's the same underlying problem.)
Blocks: majorbugs
I don't see this bug on bier.homeip.net anymore but I do see it on
http://tikiwiki.org and http://www.voip-info.org - exact same symptoms as
described in comment#0 

Actual Results: Left column is displayed correctly but all columns to the right
of it are shifted right, leaving a large blank space rendered between the 1st
and second column, meaning that the horizontal scroll bars must be used to view
the page.

Expected results: Columns are rendered without large space between left column
and others, page width fits within view without scrolling.

This is intermittent - seems to be linked to time taken for page generation by
server. Often a reload results in correct rendering of page. I have observed
this bug on all sites which use tikiwiki -  look at the comments on the bug at
the tikiwiki site for more info
http://tikiwiki.org/tiki-index.php?page=LeftColBug#comments 

IE renders page fine, observed bug in Mozilla 1.6, 1.5, firebird 0.7 and firefox
0.8 on linux and windows. 
That's offtopic, thanks to comment 21, and there have been enough bugs in this
area fixed since 1.6 that I'm not interested in whether it's broken in 1.6, ff
0.8, etc -- only whether it's broken on the trunk.
Same bug observed at www.datasport.it exactly as described in comment #22.
Tried with every Firebird/Firefox since 0.6.
Every release, or trunk builds too?  For the second or third time, it's really
only the current trunk builds that I care about.  There aren't any releases yet
that have the fixes I mentioned.

And for the third or fourth time, any sites other than the one in comment 0
should be filed in a separate bug, *if* they still occur on trunk builds.
THis should be good news for everyone involved: I just downloaded the a Firefox
nightly build, and http://www.tikiwiki.org displays fine. 

I had previously seen the same problems the ither Tiki users had seen, and I can
still reproduce them using Firefox 0.8 (only using Ctrl-F5, at the moment,
though). I've done messed about on tw.o but can't reproduce the problem in the
nightly build. (Just for completeness, I did once see a problem with the right
hand column, but I can't reproduce that, so I'm not thinking that is relevant to
this bug.)

Thankyou VERY much to dbaron and anyone ele involved for working on these nasty
table layout bugs recently. It look like you've squished this one.

FYI, here's what I tested with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040213
Firebird/0.8.0+
It's nice that that bug is fixed, because it at least means people will stop
making inappropriate comments on this bug (see comment 18, comment 21, comment
23, and comment 25), but what really matters is whether the URLs in comment 0
are fixed.
Marking worksforme.

If someone sees this in a TRUNK build (not firefox 0.8, not mozilla 1.6), please
reopen.
Status: NEW → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WORKSFORME
Sorry for the extra bugspam. I should have checked the comment 0 URLS first. 

I can't reproduce the bug with the comment 0 or comment 1 URLs now even in
Firefox 0.8 - even if I move the mouse and CTRL-F5. 

As is clear from the text in the top of those 'testcases' they were (IIUC) an
attempt at simplification of the problems TikiWiki.org were having. That
original problem is what I checked earlier.

Glad to have this fixed. Thanks again David. Hopefully no more comments on here.
Cool!  Looking forward to a new Firefox.  By the way, I use Firefox (.8) and I
get the problem all the time e.g. on http://xmleverwhere.com, which is a slower
server than tikiwiki.org apparently.  The last comment said it was rare, but for
me, it isn't, so I thought I would correct that.  Again, I understand that this
should be fixed.  Why, I'm gonna download a trunk build right now!
No longer blocks: majorbugs
You need to log in before you can comment on or make changes to this bug.