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.
Confirmed problem on Linux Build 2000052109
Confirmed Linux and Windows build 2000052120
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
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).
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.
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>
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: email@example.com → firstname.lastname@example.org block-max-width
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.)
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
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
Steve: Can you mark this nsbeta3+ if you agree, or does it need to go through another process?
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.
nominating for rtm, since it's a precieved data loss (part of the page doesn't show up)
Keywords: nsbeta3 → rtm
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: email@example.com block-max-width → firstname.lastname@example.org block-max-width[need info]
Changing [need info] to [rtm need info].
Whiteboard: email@example.com block-max-width[need info] → firstname.lastname@example.org block-max-width [rtm need info]
yes, this bug is actively being worked on. no solution yet.
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: email@example.com block-max-width [rtm need info] → firstname.lastname@example.org block-max-width [rtm-]
Target Milestone: M17 → Future
http://www.kbb.com appears to have changed so that it is now displayed correctly. Attached testcase is still rendered incorrectly, however.
QA contact update
QA Contact: chrisd → amar
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
Bumping up priority a notch...this is rather disturbing. And reassigning...
Assignee: buster → karnaze
Severity: normal → major
Status: ASSIGNED → NEW
I'll take a look at this for now.
Assignee: karnaze → waterson
Priority: P2 → P3
Target Milestone: Future → mozilla0.9.5
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
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Yes, it does appear to work on 2001092506/Linux. vrfy
Status: RESOLVED → VERIFIED
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
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.