Reproducability: Always, when on a 56 kbps connection and when the images are not in the cache Steps to reproduce: 1. Go to http://www3.pimpserver.com/www3/asiantgp/tgp/jun9/index21.html (warning -- contains porn!) 2. Immediately scroll down about one page Expected Result: As the page loads, the images shift to accomodate the new images. Actual Result: As the page loads, the images shift and are not redrawn properly. If the window is scrolled down at least a page and scrolled back up, the images appear properly. I've noticed this behavior with the latest few nightly builds, including 2001061504, on Windows 98.

mmmh... sweeeet pr0n.... *cough* i mean, are u sure it's a table problem and not an image rendering problem?

In the table of graphics I attached (no pr0n, sorry), as the graphics are downloaded, the text below the graphics are sometimes not reflowed properly. It looks like this is a problem with the table reflow and not the graphics.

No matter how many times I look at this porn, I cannot reproduce this problem :-) But seriously, on build 20010710 everything seems to flow into place properly. Reporter, could you perhaps post a screenshot of the behavior in question? I'm still a little unclear exactly what the problem is.

WORKSFORME platform: PC OS: Windows 98 Mozilla Build: 2001072003

Marking WORKSFORME OS: Windows 2000 Build: 2001072108 Reporter if you still see this bug on a recent build please reopen...

I'm still seeing this problem with build 2001073003.

Reopening.

I can confirm this now. (I know looking at the porn long enough would work. :-) The steps to reproduce must be followwed exactly. You have to be viewing the table in question while it loads. I can't get the attached (non-porn) testcase to reproduce however. Steps to reproduce. The instant you have scrollbars to do so, scroll down one page to "School Girl Japanses Fucking Gallery" (sic) watch as the table loads. (do not scroll anymore) images get bumped around and when its finally done you're left with stuff overlapping. Once loading is finished, scroll up or down to get the table off the screen. When you come back the table will be messed up. (This is also true if you place another window over this one.) It would be nice if someone could develop a working testcase that doesn't involve porn. (especially porn involving people of questionable age.) You may need to throttle your connection to be able to witness the table problems. (why its always reproducable on a 56K connection) Confirming and moving severity to minor, as all you have to do is scroll to get everything right again.

We need a reduced test case. Surely, someone must be interested.

I guess I don't have the permissions needed to add the "testcase" keyword, so can someone else do that for me? The problem I testcased isn't exactly the same as the one shown in schapel's screenshot, but hopefully it's the same underlying problem. I testcased the problem where images in the left column of the second table of thumbnails are sometimes drawn like this: /------\ | | | | | | \------/ 7.jpg in the bottom row of the second table of thumbnails is wider than the other thumbnail images in its column. When the image loads, it causes that column to expand, because the page author did not include width= and height= attributes for the thumbnails. Mozilla moves the other columns around to give the column more room, but it forgets to redraw the column on the left. I replaced the image with some JavaScript that makes a bit of text expand when you mouse over it. The timing of the image load seemed to depend on too many things, such as connection speed and the presence of other images on the page.

The original URL is now giving a 404 Error. Updating the URL to a page that better demonstrates the problem. To reproduce, make sure your browser window is at least 600 pixels tall, and then click on the URL. It occurs reliably with a 56K connection for me. To reproduce the problem again, you may need to clear the cache before you reload the page. As with the original URL, if you hide the browser window in any way, the page is painted correctly when it is uncovered. The first test case I attached is now working correctly with the latest builds. I have a new test case that is simply the first two rows of that test case, and it also reliably reproduces the problem with a 56K connection.

reassigning to m0.9.6

*** Bug 96441 has been marked as a duplicate of this bug. ***

Adding nsbranch, since it is low risk and is causing editor problems.

Very safe fix, invalidates table when width changes. Previously it did not invalidate the table when the width changed which caused rendering problems in composer when typing into tables. Marking nsbranch+

*** Bug 57618 has been marked as a duplicate of this bug. ***

Anybody test the performance implications of this yet? I tried the patch on my tree and its fine but my box is too fast for eyeballing performance problems.

Does this patch have an r/sr=? If yes, let's talk about getting it into the branch at today's PDT.

Comment on attachment 46887 [details] [diff] [review] patch without some left over changes (2nd try, ignore previous one) r=kmcclusk@netscape.com

Comment on attachment 46887 [details] [diff] [review] patch without some left over changes (2nd try, ignore previous one) sr=attinasi

Safe, but not one we need to take for 094 ... sorry = PDT-

karnaze: this has r= and sr=; why not check it in? :-) Gerv

The patch is in. If problems remain with testcase id=50409, please file a new bug.

gratuitous verify : been checked in for quite some time