both columns of the table aren't always entirely displayed




19 years ago
17 years ago


(Reporter: vanbalen, Assigned: waterson)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: block-max-width [rtm-], URL)


(1 attachment)



19 years ago
Overview Description: 

Table containing different topics of site (I.e. "Used car values",
"Motorcycles", etc) doesn't always finish displaying (second column doesn't
appear until page is reloaded).

Steps to Reproduce: 
1) Go to
2) Look for second column of table containing "New car pricing", "Buying &
Selling", "More Research" (it's not there).
3) For this column to appear, reload the page.


You should be able to reproduce it since it's done the same thing every time
I've tried it.

Build Date & Platform Bug Found: 

Linux build from 05/22/00 running on Compaq Deskpro w/t PIII 500

Additional Builds and Platforms Tested On: 


Comment 1

19 years ago
Confirmed problem on Linux Build 2000052109

Comment 2

19 years ago
Confirmed Linux and Windows build 2000052120
Ever confirmed: true
Keywords: makingtest
OS: Linux → All

Comment 3

19 years ago
Created attachment 9021 [details]
Simplified Testcase

Comment 4

19 years ago
Note with the testcase:
It the testcase appears to work fine when you click on the link above for the 
attachment.   To see the behavior I was seeing, save the attachment to your 
local hard drive and then open up mozilla and look at it.
Keywords: makingtest → testcase

Comment 5

19 years ago
I'm getting erroneous behavior with build 2000052208 when clicking on the link

without saving to my HDD (second dragon doesn't show until page is reloaded).


Comment 6

19 years ago
and then it fixes itself and makes a fool out of me... a cache issue, maybe?
Can't tell cuz I can't seem to clear the cache, if there's actually one being

Comment 7

19 years ago
Yes, if the page is cached, there's a good chance that it'll show up correctly.
 Very odd behavior.      To make sure that's it's not being cached, try making
your own HTML file on your computer.   Copy and paste this in:


<IMG SRC="">

<IMG SRC="">


Comment 8

19 years ago
Buster, using the example in the 5/24 comments, and running it the first time 
(it works on subsequent reloads), it looks like the block of the outer table's 
cell is returning a max width that is about half of what it should be during an 
incremental reflow (last line below). It looks like the block's max width is 
limited by the avail width, but the cell doesn't know that its block is 
expanding and uses what it had last for an avail width.

             Area::Rfl en 011F2044 rea=1 av=(1050,UC) comp=(1050,UC) count=99
             TO::Rfl en 011F20CC rea=2 av=(1050,UC) comp=(UC,0) count=100
               T::Rfl en 011F2120 rea=2 av=(1050,UC) comp=(UC,UC) count=101
                 TRG::Rfl 011F218C rea=2 av=(1050,UC) comp=(1050,UC) count=102
                   TR::Rfl en 011F21D0 rea=2 av=(1050,UC) comp=(1050,UC) count=1
                   TR::Rfl ex 011F21D0 des=(1020,990)
                TRG::Rfl ex 011F218C des=(1050,990)
              T::Rfl ex 011F2120 des=(1050,1050) maxElem=(0,0)
            TO::Rfl ex 011F20CC des=(1050,1050) maxElem=(1050,0)max=1050
            TO::Rfl en 011F20CC rea=2 av=(1050,UC) comp=(UC,0) count=104
               T::Rfl en 011F2120 rea=2 av=(1050,UC) comp=(UC,UC) count=105
                 TRG::Rfl 011F218C rea=2 av=(1050,UC) comp=(1050,UC) count=106
                   TR::Rfl en 011F21D0 rea=2 av=(1050,UC) comp=(1050,UC) count=1
                   TR::Rfl ex 011F21D0 des=(1020,990)
                TRG::Rfl ex 011F218C des=(1050,990)
              T::Rfl ex 011F2120 des=(1050,1050)
            TO::Rfl ex 011F20CC des=(1050,1050)
            TO::Rfl en 011F2518 rea=1 av=(0,UC) comp=(0,0) count=108
               T::Rfl en 011F256C rea=1 av=(0,UC) comp=(UC,UC) count=109
                 TRG::Rfl 011F25D8 rea=1 av=(1050,UC) comp=(1050,UC) count=110
                   TR::Rfl en 011F261C rea=1 av=(1050,UC) comp=(1050,UC) count=1
                     TC::Rfl 011F2664 rea=1 av=(990,UC) comp=(960,UC) count=112

                       Area::Rfl en 011F26C0 rea=1 av=(960,UC) comp=(960,UC) cou
                       Area::Rfl ex 011F26C0 des=(960,960) maxElem=(960,960)max=
                    TC::Rfl ex 011F2664 des=(990,990) maxElem=(990,990)max=990
                  TR::Rfl ex 011F261C des=(1050,990) maxElem=(990,990)max=0
                TRG::Rfl ex 011F25D8 des=(1050,990) maxElem=(990,990)max=0
              T::Rfl ex 011F256C des=(1050,1050) maxElem=(1050,990)max=1050
            TO::Rfl ex 011F2518 des=(1050,1050) maxElem=(1050,0)max=1050
            Area::Rfl ex 011F2044 des=(2100,1050) maxElem=(1050,0)max=1050
Assignee: karnaze → buster
Whiteboard: → block-max-width


19 years ago
Priority: P3 → P2
Target Milestone: --- → M17


19 years ago
Priority: P2 → P1

Comment 9

19 years ago
Just re-tested this bug with 2000072113/Linux and can no longer get the right
hand column to display after reloading page. It will show up for a second or two
and then disappear.
Reproducible 99.9% of the time (It appears to display both columns without any
trouble when I open a new browser window and paste the URL directly onto the
browser!... I.e. not into the location bar and then hit enter but directly onto
the browser.) 

Comment 10

19 years ago
nominating this one for nsbeta3.  Causes part of a page to not display in a
fairly common case (an image in a table where the image has no width attribute
specified, so we don't know the image dimensions until after the image loads.)
I think this is more important and lower risk than anything currently on my
beta3 list that I don't already have a fix for.
Est. time to fix: 1 day.  I've fixed bugs similar to this, and I have some
confidence I know what to look for.
Est. risk of fix:  low to moderate.
Keywords: nsbeta3

Comment 11

19 years ago
should be marked nsbeta3+ P2. Should be fixed due to visual data loss, but
wouldn't hold up fcs for it if I can't get it fixed in the next few days.
Priority: P1 → P2

Comment 12

19 years ago
Steve: Can you mark this nsbeta3+ if you agree, or does it need to go through 
another process?

Comment 13

19 years ago
the process is for the assigned engineer to make a recommondation, and the
manager (chris k. in my case) to approve or not based on the severity, frequency
of occurance, and risk to fix.

Comment 14

19 years ago
nominating for rtm, since it's a precieved data loss (part of the page doesn't
show up)
Keywords: nsbeta3 → rtm

Comment 15

19 years ago
Are you actually working on this?  If so, please put [rtm need info] in the 
status whiteboard.  If not, please mark rtm-.

Does the page reflow after the image finishes loading?  If so, maybe this is 
Whiteboard: block-max-width → block-max-width[need info]

Comment 16

19 years ago
Changing [need info] to [rtm need info].
Whiteboard: block-max-width[need info] → block-max-width [rtm need info]

Comment 17

19 years ago
yes, this bug is actively being worked on.  no solution yet.

Comment 18

19 years ago
marking rtm-  There seems to be substantial risk in fixing this bug.  Although
it can lead to a percieved data loss under rare circumstances, I think we'll
have to live with it for NS6 RTM.
Whiteboard: block-max-width [rtm need info] → block-max-width [rtm-]
Target Milestone: M17 → Future

Comment 19

18 years ago appears to have changed so that it is now displayed
correctly. Attached testcase is still rendered incorrectly, however.

Comment 20

18 years ago
URL no longer displays problem. Removing.
QA contact update
QA Contact: chrisd → amar

Comment 22

18 years ago
Anyone still looking at this?... What really scares me about this bug is that I
(and who knows how many other people) could well be seeing this every day and
not even know it, especially now that reloading the page doesn't recover the
lost content.
Could cause "missing" content, testcase also looks like it could be fairly
common markup - nominating for mozilla1.0
Keywords: mozilla1.0
Bumping up priority a notch...this is rather disturbing.  And reassigning...
Assignee: buster → karnaze
Severity: normal → major

Comment 25

18 years ago
I'll take a look at this for now.
Assignee: karnaze → waterson
Priority: P2 → P3
Target Milestone: Future → mozilla0.9.5

Comment 26

18 years ago
I'm not able to reproduce the problem: tried saving the test case to my HD,
flushing cache, restarting, waving chicken, etc. Marking WORKSFORME.
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 27

18 years ago
Yes, it does appear to work on 2001092506/Linux.
When I just load the testcase, it looks fine.  Reloading will make the second
picture be cut off.  Linux build 2002-01-07-06 and Linux cvs build from 2002-01-11

Comment 29

17 years ago
I just retested with 2002032808 and got the behavior bzbarsky described
(shift+reload causes truncation of second image and regular reload causes both
images to show up). I this a different bug?
You need to log in before you can comment on or make changes to this bug.