The images in the left hand frame of the URL are not wrapping. They should.

Accepting and cc'ing original reporter, Jonas.

I think we need to detect when the text between the images is whitespace only and then NOT accumulate the image widths since that keeps them from wrapping.

I attached a patch to fix this problem, and also correct a couple of mistakes in the prior implementation. Now we just check if the current frame is or has an image, or is a non-whitespace text frame and an element with a combined width equal to the maxelemement width. This covers the cases of spaces and newlines between the images, and also text with whitespace inside the text. The testcase attached is fixed, but I still need to check the older tests and URLs (I did test some URLs, like newport-news.com, and they are still OK). I plan to create a more comprehensive testcase for the regression tests too. If anyone else wants to test, please try the patch!

NOTE: this was sorta spun off from bug 100568, fwiw.

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

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

Yer killin' me with the zero context lines, man! :-) Couple nits that might be worth cleaning up, but in general this looks great. (I think I might actually understand it now!) 1. Looks like there could be some indentation problems around frameCount++. 2. You can probably fit if (!strictMode && inUnconstrainedTable) { on the same line now. 3. Looks like the |inChild| argument to AccumulateImageSizes is no longer necessary. 4. Might want to move the comment about checking maxElementWidth vs. combinedArea.width down to where you do the check (since its moved). r= or sr= waterson, whichever helps.

r/sr=hyatt

Sorry about the patch - I blame Mac CVS ;) I should have looked at it myself, ack! I'll clean it up as you recommend. Thanks.

Comment on attachment 50846 [details] [diff] [review] Patch to fix this bug and make the logic for image size accumulation much more rational Updated with Waterson's comments (and some context lines)

Updating summary: have review and super review, checking in to trunk.

Comment on attachment 51263 [details] [diff] [review] Updated patch r and sr in comments...

pls go ahead and check this in - PDT+

Fix checked into trunk and 0.9.4 branch

say, 102119 didn't get fixed after this, has it been checked into 2001092803?

just a note: bug 102119 no longer a problem, fixed in 2001092908. Cool!

Verified with the Oct 4th branch build under Mac OS X (2001-10-04-04) and Windows ME (2001-10-04-06).

Verified on Linux Redhat 6.2 (2001-10-04-04)