40129 - both columns of the table aren't always entirely displayed

Reporter

Description

•

25 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 www.kbb.com 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. Reproducibility: 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: None.

Jeffrey Baker

Comment 1

•

25 years ago

Confirmed problem on Linux Build 2000052109

WD

Comment 2

•

25 years ago

Confirmed Linux and Windows build 2000052120

URL: www.kbb.com → http://www.kbb.com

Status: UNCONFIRMED → NEW

Ever confirmed: true

Keywords: makingtest

OS: Linux → All

Whiteboard: wdormann@crosswinds.net

WD

Comment 3

•

25 years ago

Attached file Simplified Testcase (deleted) — Details

WD

Comment 4

•

25 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

Dave

Reporter

Comment 5

•

25 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).

Dave

Reporter

Comment 6

•

25 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 created.

WD

Comment 7

•

25 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: <html> <TABLE><TR><TD> <TABLE ALIGN=LEFT> <TR><TD> <IMG SRC="http://home.netscape.com/home/demo/1.1b1/mozilla/Aj.gif"> </TD> </TABLE> <TABLE> <TR><TD> <IMG SRC="http://home.netscape.com/home/demo/1.1b1/mozilla/Aj.gif"> </TD> </TABLE> </TABLE> </html>

karnaze (gone)

Comment 8

•

25 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 03 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 07 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 11 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 nt=113 Area::Rfl ex 011F26C0 des=(960,960) maxElem=(960,960)max= 960 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: wdormann@crosswinds.net → wdormann@crosswinds.net block-max-width

buster

Updated

•

25 years ago

Priority: P3 → P2

Target Milestone: --- → M17

buster

Updated

•

24 years ago

Priority: P2 → P1

Dave

Reporter

Comment 9

•

24 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.)

buster

Comment 10

•

24 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.

Status: NEW → ASSIGNED

Keywords: nsbeta3

buster

Comment 11

•

24 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

Christine Hoffman

Comment 12

•

24 years ago

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

buster

Comment 13

•

24 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.

buster

Comment 14

•

24 years ago

nominating for rtm, since it's a precieved data loss (part of the page doesn't show up)

Keywords: nsbeta3 → rtm

selmer (gone)

Comment 15

•

24 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 invalid...

Whiteboard: wdormann@crosswinds.net block-max-width → wdormann@crosswinds.net block-max-width[need info]

karnaze (gone)

Comment 16

•

24 years ago

Changing [need info] to [rtm need info].

Whiteboard: wdormann@crosswinds.net block-max-width[need info] → wdormann@crosswinds.net block-max-width [rtm need info]

buster

Comment 17

•

24 years ago

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

buster

Comment 18

•

24 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: wdormann@crosswinds.net block-max-width [rtm need info] → wdormann@crosswinds.net block-max-width [rtm-]

Target Milestone: M17 → Future

Dave

Reporter

Comment 19

•

24 years ago

http://www.kbb.com appears to have changed so that it is now displayed correctly. Attached testcase is still rendered incorrectly, however.

Dave

Reporter

Comment 20

•

24 years ago

URL no longer displays problem. Removing.

URL: http://www.kbb.com → See testcase

Amarendra Hanumanula

Comment 21

•

24 years ago

QA contact update

QA Contact: chrisd → amar

Dave

Reporter

Comment 22

•

23 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.

Mats Palmgren (inactive)

Comment 23

•

23 years ago

Could cause "missing" content, testcase also looks like it could be fairly common markup - nominating for mozilla1.0

Keywords: mozilla1.0

Christopher Hoess (gone)

Comment 24

•

23 years ago

Bumping up priority a notch...this is rather disturbing. And reassigning...

Assignee: buster → karnaze

Severity: normal → major

Status: ASSIGNED → NEW

Chris Waterson

Assignee

Comment 25

•

23 years ago

I'll take a look at this for now.

Assignee: karnaze → waterson

Priority: P2 → P3

Target Milestone: Future → mozilla0.9.5

Chris Waterson

Assignee

Comment 26

•

23 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.

Status: NEW → RESOLVED

Closed: 23 years ago

Resolution: --- → WORKSFORME

Dave

Reporter

Comment 27

•

23 years ago

Yes, it does appear to work on 2001092506/Linux. vrfy

Status: RESOLVED → VERIFIED

Boris Zbarsky [:bzbarsky]

Comment 28

•

23 years ago

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

Dave

Reporter

Comment 29

•

23 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?