From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.1 (X11; Linux i686; U;) Gecko/20011226 BuildID: 2001122617 The inset graphic on the right side of the screen renders incorrectly. The graphic partially obscurs and interferes with the rendering of the right-hand sidebar. Reproducible: Always Steps to Reproduce: 1.Visit the URL Actual Results: Same as in the description above Expected Results: I'm not sure as I can't access another modern browser at this time.

Confirmed. This appeared when I first loaded the page and reloaded, but both going back and then to the page again, and viewing in DOM Inspector, resulted in correct rendering.

Hmmm...how do you do what you described? I popped open the DOM inspector and worked my way down the tree to that IMG tag and it still was mis-rendered. Then, I went to another page and back to it and it still mis-rendered. :) Thanks! --Jason

Looks like a floater issue. Reassigning to Alex.

is displayed correctly if you hit corectly if back/fwd or fwd/back with 2002013103(w32) and 2002011408(linux). I will attach a testcase

i tested the URL with 2002013103(win32) and 2002011408(linux) and if you hit back/fwd or fwd/back the page displays correctly

Yes, it does with my mozilla now. Any idea why it doesn't rener properly initially? Thanks! --Jason

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

Moving to Mozilla1.1. Engineers are overloaded with higher priority bugs.

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

duplicate of bug 97057?

Removed a few unnecessary elements.

This trace is the incremental reflow of the image frame, which makes me think this is _not_ a floater bug, but a table incremental reflow bug. Notice that the table cell's width is correctly increased, but the row and the rowgroup do not expand horizontally.

-> tables.

Hmmkay. My bad: I dug a little deeper and it looks like we're not updating the MES when we incrementally reflow that floater. Taking back...

Okay, here's what's happening AFAICT. 1. The inline frame is being asked to compute its MES by the outer table. So, it does an unconstrained reflow of its lines. 2. The floated table frame is flowed by its placeholder frame at an unconstrained width. It correctly detects that it's going to need to do a second-pass reflow when the incremental reflow is processed by the cell. 3. However, on the way _out_ of the reflow, it never bothers doing the second- pass reflow, assuming that since it's gotten an unconstrained reflow, it'll get flowed again. (See nsTableFrame.cpp:2141.) 4. Therefore, the floated element is returned the original table cell's width, which it assumes is the MES, and stores it away. 5. We return back out to the inline frame, which now reflows the line again, but this time _without_ requesting that its children compute MES. 6. We return the narrower MES out to the enclosing table, and things look wrong. So, it seems to me that the table frame shouldn't be deferring that second-pass reflow in (3), above. Or, we should be requesting that children compute the MES *again* during the second-pass line reflow in (5).

So, one way to do this is to allow the second-pass reflow to happen when the table detects that it needs rebalancing, and _either_ it's not an unconstrained reflow, or the MES is being requested.

This patch does not fix bug 141021 (but I'll be attaching another patch to that bug shortly).

karnaze, it looks like you've got this covered. ;-)

Comment on attachment 82656 [details] [diff] [review] revised patch (a little more efficient) r=bernd

Comment on attachment 82656 [details] [diff] [review] revised patch (a little more efficient) sr=waterson

FIXED_ON_TRUNK

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

According to Bernd, this patch might have fixed http://www.nexgenmedia.net/evang/ftd.de/, which is a simplified testcase of a german topsite/AOL Partner (bugscape 16499). If so, this should go into the branch for MachV.

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

amar: can you pls verify this as fixed, and check around for any possible regressions. thanks!

Jaime: This bug is fixed on the trunk. Its not checked into branch. This bug still exists on branch build: 2002-08-05-12-1.0. Verified fixed on trunk build: 2002-08-05-08-trunk. No regressions found on trunk.

Marking as Verified for the trunk per Comment #29 From Amarendra Hanumanula.

mass changing adt1.0.1 to adt1.0.2 nominations.

mozilla1.0.1 has passed. carrying over nomination to mozilla1.0.2 (and adding topembed+), as this fixes a topsite in germany.

This bug does not meet the Blackbird criteria, adt-