Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 207208 - {inc}Table lays out too wide when image is not pulled from image cache
: {inc}Table lays out too wide when image is not pulled from image cache
: testcase, topembed
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: PowerPC All
: P2 normal (vote)
: ---
Assigned To: Bernd
: Madhur Bhatia
Depends on:
  Show dependency treegraph
Reported: 2003-05-27 02:59 PDT by Brian Ryner (not reading)
Modified: 2003-07-29 23:44 PDT (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

gif file #1 for testcase (156 bytes, image/gif)
2003-05-27 03:00 PDT, Brian Ryner (not reading)
no flags Details
gif file #2 for testcase (2.19 KB, image/gif)
2003-05-27 03:01 PDT, Brian Ryner (not reading)
no flags Details
gif file #3 for testcase (669 bytes, image/gif)
2003-05-27 03:02 PDT, Brian Ryner (not reading)
no flags Details
html for testcase (872 bytes, text/html)
2003-05-27 03:07 PDT, Brian Ryner (not reading)
no flags Details
reflow log from the table sizing too wide (7.60 KB, text/plain)
2003-05-27 03:57 PDT, Brian Ryner (not reading)
no flags Details
reflow log with the width=201 workaround (6.78 KB, text/plain)
2003-05-27 03:59 PDT, Brian Ryner (not reading)
no flags Details
patch (2.14 KB, patch)
2003-05-30 23:18 PDT, Bernd
john: review+
dbaron: superreview+
Details | Diff | Splinter Review

Description Brian Ryner (not reading) 2003-05-27 02:59:02 PDT
If you visit this site for the first time or shift+reload it, you'll likely see
a large horizontal gap down the middle of the page.  I reduced this down to an
apparent timing problem where if  we don't know an image's size up front, we end
up allocating too much space for the table.  I have a reduced testcase that I'll
be attaching in a minute.
Comment 1 Brian Ryner (not reading) 2003-05-27 03:00:34 PDT
Created attachment 124264 [details]
gif file #1 for testcase
Comment 2 Brian Ryner (not reading) 2003-05-27 03:01:26 PDT
Created attachment 124265 [details]
gif file #2 for testcase
Comment 3 Brian Ryner (not reading) 2003-05-27 03:02:06 PDT
Created attachment 124266 [details]
gif file #3 for testcase
Comment 4 Brian Ryner (not reading) 2003-05-27 03:07:39 PDT
Created attachment 124267 [details]
html for testcase

To see the problem, load this attachment and notice the dark blue strip to the
extreme right.	Click reload (not shift+reload) and notice that it goes away. 
The second behavior, when the image is cached, is the correct layout.
Comment 5 Brian Ryner (not reading) 2003-05-27 03:16:21 PDT
I should also note that here:

        <td width="170" align="left" valign="top">
          <img src="
view" border="0">

if I add width="201" to the <img> tag (that's the actual image width), the
problem goes away.  This seems to support the theory that not knowing the image
size up front causes a problem.
Comment 6 José Jeria 2003-05-27 03:26:13 PDT
What Mozilla version do you use. 
Comment 7 Brian Ryner (not reading) 2003-05-27 03:56:33 PDT
This is with a current CVS build.
Comment 8 Brian Ryner (not reading) 2003-05-27 03:57:48 PDT
Created attachment 124272 [details]
reflow log from the table sizing too wide
Comment 9 Brian Ryner (not reading) 2003-05-27 03:59:42 PDT
Created attachment 124273 [details]
reflow log with the width=201 workaround

I wanted to get a reflow log for reloading and pulling the image from the
cache, but Mac viewer wasn't cooperating.  So, instead, I added width=201 to
the image, which I'm hoping has the same effect (the image width is known
Comment 10 tenthumbs 2003-05-27 04:13:41 PDT
Take a look at bug 207005 which appears to have similar symptoms.
Comment 11 Dan Backes 2003-05-27 14:58:30 PDT
Confirmed with 2003052708 winXP
Comment 12 Brian Ryner (not reading) 2003-05-28 02:32:16 PDT
Bernd, do you happen to know where the code is at that's supposed to handle a
pixel width specified on a cell, where the cell's contents are wider than that?
 Any other ideas on this bug?
Comment 13 David Baron :dbaron: ⌚️UTC-7 2003-05-28 11:30:07 PDT
The width attribute on TD (and unfortunately the CSS 'width' property as well)
acts like 'min-width', not 'width'.  So without the image, there's a good bit of
extra space to distribute in the table, but once the image arrives, it isn't
redistributed (probably the code calls it rebalanced) the same way it would have
been had the image been there initially.
Comment 14 Bernd 2003-05-29 00:04:32 PDT
Its like dbaron said, we are missing a table rebalance once the cell size
changed on the incremental reflow. The functions to indicate this are -
SetNeedStrategyBalance  the soft variant

and - 
SetNeedStrategyInit the hardcore reset.

The debugging of the table layout strategy is documented at . Its very
unlikely that the layout strategy is wrong, its more likely the necessary flag
is not set at all or the too soft flag is set. Setting these flags is
*expensive* as a rebalance causes a resize reflow for all table children.

off topic:

          block 0x182f410 r=0 a=UC,UC c=UC,UC cnt=22 
           text 0x182f570 r=0 a=UC,UC c=UC,UC cnt=23 
           text 0x182f570 d=0,0 me=0 
           img 0x182f7e0 r=0 a=UC,UC c=UC,UC cnt=24 
           img 0x182f7e0 d=360,360 me=360 
           text 0x182f860 r=0 a=UC,UC c=UC,UC cnt=25 
           text 0x182f860 d=60,240 me=0 
          block 0x182f410 d=360,360 me=360 o=(0,0) 360 x 420

I am very suspicous that a block on a unconstrained inital reflow produces an
Comment 15 David Baron :dbaron: ⌚️UTC-7 2003-05-29 10:59:10 PDT
> Setting these flags is
> *expensive* as a rebalance causes a resize reflow for all table children.

Why?  That seems ridiculous.
Comment 16 Bernd 2003-05-29 13:07:36 PDT
s/all table children/all table children that should change theire size due to
the changed column widths/ 
Comment 17 Samir Gehani 2003-05-30 16:14:27 PDT
adt: need info.  Brian, is this a regression from Mach V?
Comment 18 Bernd 2003-05-30 23:18:46 PDT
Created attachment 124623 [details] [diff] [review]

This bug is certainly not a recent regression. Like I said before the problem
was that on change of the cell-mew the columns have been only rebalanced (too
soft). The space distribution for colspan is done during the
strategy-initialize. So whenever a colspan is involved the strategy needs to be
reinitialized. In nsTableFrame::CellChangedWidth we checked before that from a
previous column a cell spans into the current column, but we did not check that
a colspan originates from the column itself.

There was already a stub for the necessary function in nsTableFrame.h. So I
wrote the implementation. And the code in nsCellMap.cpp, as it was never used
before, was plain wrong (it was copied from the row code above).
Comment 19 Bernd 2003-05-30 23:20:07 PDT
taking the bug, this is not only a Mac problem
Comment 20 Samir Gehani 2003-06-03 16:47:51 PDT
adt: nsbeta1+/adt3
Comment 21 David Baron :dbaron: ⌚️UTC-7 2003-06-09 09:34:27 PDT
Comment on attachment 124623 [details] [diff] [review]

sr=dbaron if you remove the tab that you copied (and the original as well, if
you want).
Comment 22 Bernd 2003-06-09 22:47:29 PDT
fix checked in into trunk
Comment 23 Paul Wyskoczka 2003-06-10 11:36:39 PDT
a=adt Please land this fix on the 1.4 branch and add the fixed1.4 keyword.
Comment 24 Brian Ryner (not reading) 2003-06-10 12:54:53 PDT
Comment on attachment 124623 [details] [diff] [review]

requesting drivers approval to land on 1.4 branch.
Comment 25 Brian Ryner (not reading) 2003-06-23 16:42:50 PDT
Comment on attachment 124623 [details] [diff] [review]

I think this is too late for 1.4.
Comment 26 Bernd 2003-07-29 23:44:47 PDT
this bug is fixed on the trunk and did not go into the branch, so marking it fixed

Note You need to log in before you can comment on or make changes to this bug.