Closed Bug 1613 Opened 26 years ago Closed 26 years ago

frameset doesn't display content that is too tall

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P2)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: chrispetersen, Assigned: karnaze)

References

(
URL
)

Details

Build Version: 11/23a
Platform: Windows NT 4.0, Win 95
Application: xpviewer and viewer

1) Launch either application: xpviewer and viewer
2) In the location field, type http://www.hotwired.com and press enter key.
3) After site loads, click the back button.
4) The application attempts to navigate to the previous site but then crashs
XPVIEWER caused a invalid page fault in module RAPTORHTML.DLL.
I actually see this going to any site after hotwired.com, or clicking on any
link on hotwired, or... you get the picture.
Taking off ss: list per bug mtg today.  Release Note - Back button on frame
sites will fail.

BUT - would like to fix ASAP if possible.
Leaving on ss: for now.
Assignee: karnaze → kipp
Going to hotwired and then hitting the back button in the viewer crashes with
the following stack. The nsFrameImageLoader's mTargetFrame has been deleted
without it knowing about it.

nsFrame::GetOffsetFromView(const nsFrame * const 0x014be5a0, nsPoint & {...},
nsIView * & 0x00000000) line 1398 + 13 bytes
nsFrameImageLoader::DamageRepairFrame(const nsRect * 0x0012fc6c) line 337
nsFrameImageLoader::Notify(nsIImageRequest * 0x014af410, nsIImage * 0x01483610,
nsImageNotification nsImageNotification_kPixmapUpdate, int 0, int 0, void *
0x0012fcb4) line 217
ns_observer_proc(void * 0x014b0b00, long 4, void * 0x0012fd3c, void *
0x014af410) line 269
XP_NotifyObservers(OpaqueObserverList * 0x014b0a90, long 4, void * 0x0012fd3c)
line 259 + 28 bytes
il_pixmap_update_notify(il_container_struct * 0x014b08a0) line 155 + 18 bytes
il_flush_image_data(il_container_struct * 0x014b08a0) line 225 + 9 bytes
il_gif_write(il_container_struct * 0x014b08a0, unsigned char * 0x002f1778, long
0) line 1417 + 9 bytes
process_buffered_gif_input_data(gif_struct * 0x014bdd80) line 622 + 16 bytes
gif_delay_time_callback(void * 0x014bdd80) line 657 + 9 bytes
timer_callback(nsITimer * 0x012fa6b0, void * 0x012fa700) line 70 + 12 bytes
TimerImpl::Fire(unsigned long 109787646) line 308 + 17 bytes
TimerImpl::ProcessTimeouts(unsigned long 109787646) line 187
FireTimeout(void * 0x00000000, unsigned int 275, unsigned int 24903, unsigned
long 109787646) line 101 + 9 bytes
USER32! 77e7128c()
main(int 1, char * * 0x01209330) line 96
mainCRTStartup() line 338 + 17 bytes
Status: NEW → ASSIGNED
Assignee: kipp → buster
Status: ASSIGNED → NEW
the crash is occuring because an image load is being started on a frame, and
that frame is not deleted when the frameset is torn down. I believe that the
reason for this is because the table code is not reflowing itself properly.

Here is a simple test case that recreates the problem:

--CUT--
<frameset rows="68,*,20%">
 <frame src=1613-1.html scrolling=no>
 <frame src=woofer.gif>
 <frame src=woofer.gif scrolling=no>
</frameset>
--CUT--

here is 1613-1.html:
--CUT--
<html><head>

</head>

<body bgcolor="#000000">


<TABLE nowrap cellpadding="2" cellspacing="0" border="0" width="600"
bgcolor="#000000">
<TR align="center">
<TD valign="top" align="left">
<a
href="http://nsads.hotwired.com/event.ng/Type=click&ProfileID=1574&RunID=9321&Ad
ID=12212&GroupID=1&FamilyID=1106&TagValues=2.5.6.25.156.159.176.179.180.182.183.
185.196.197.198.208.242.374.389.411.526.6370&Redirect=http:%2F%2Fonl.uophx.edu%2
Fdefault.asp%3Fplace%3D340G" TARGET="_top"><img
src="http://static.wired.com/advertising/blipverts/univ_of_phoenix/468going.gif"
BORDER=1 height=60 width=468 alt="Click here for the University of Phoenix
Online"></a>&nbsp;</TD>
<td valign="top" align="left">
<a
href="http://nsads.hotwired.com/event.ng/Type=click&ProfileID=5770&RunID=9113&Ad
ID=13822&GroupID=1&FamilyID=707&TagValues=2.5.6.25.159.179.180.182.183.185.196.1
97.198.208.241.242.374.389.411.526.6370.6883.70367&Redirect=http:%2F%2Fwww.music
blvd.com%2Fcgi-bin%2Ftw%2F3291_0_bb%2Fbb200.txt^S%26FS%3DHOTBOT
" TARGET="_top"><img
src="http://static.wired.com/advertising/blipverts/music_blvd/bill_12060.gif"
BORDER=1 height=60 width=120 alt="Click here for Music Boulevard"></a></td>
</TR>
</TABLE>

</body></html>

--CUT--
I've checked in fixes to both the branch and tip that eliminate the crash with
this site. Now it's up to steve to eliminate the memory leak.
Severity: critical → major
Status: NEW → ASSIGNED
Priority: P1 → P2
Summary: ss:Clicking the back button after visiting the hotwired site will cause a crash. → memory leak leaving page.
with Kipp's fix of the crash, I believe this should be removed from the "ss"
list.  we can ship this milestone with a few minor memory leaks.  I am changing
the priority and severity to fit the new description.  Summary was:
ss: Clicking the back button after visiting the hotwired site will cause a
crash.
sujay - can you please verify that crash no longer occurs with Nov 28 build when
it comes out?  Thanks!
Works with no crash on 11/28 build on NT. Leaving for Sujay to close.
Please don't close.  Leave as is (Assigned) for the memory leak fix.  Thanks!
Assignee: buster → karnaze
Status: ASSIGNED → NEW
I don't understand why Chris thinks this has anything to do with tables.  The
only relevant memory leak I see on this page is in
nsHTMLFramesetFrame::CalculateRowCol.  It leaks every time its called - the
normal method exit path does not clean up "fixed", "percent", or "relative".
Chris and Kipp, if you think any part of the memory leak on this page is due to
tables, please assign back to me with a description of what leads you to
believe tables are involved.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Assignee: karnaze → buster
Status: REOPENED → NEW
if you look at the page, you will see *nothing* in the bottom table. THe reason
is that the area is just a bit too *short*.

If you then dump the frame tree you will notice that the bottom most frame cell
has a table in it, which has no content. However, if you compare that with the
content model you will see that they disagree.

During debugging of the crash (part of the initial report) I noticed that frames
were being created for loading animaged images. Later, we would crash because
those frames were not getting destroyed. At this point I dumped out the frame
tree and lo and behold - most of the tables frames were gone.
Resolution: FIXED → ---
Status: NEW → ASSIGNED
Assignee: buster → karnaze
Status: ASSIGNED → NEW
Component: Viewer App → HTMLFrames
Summary: memory leak leaving page. → frameset doesn't display content that is too tall
changed summary to reflect that the originally reported problem is fixed, and
we're dealing with something else entirely here.
The problem seems to be that the table wants to be taller than the available
space.  Kipp reported that he saw a corrupt frame dump in this case, which I
don't see.  I simply see that the table frame is missing from it's parent, the
body in frame 3.
I believe the table code is doing the right thing.  The table code is setting
the size of the table based on the table content.  The frameset should show as
much of the table as it can.  I have included a test case here that does not
even have a table, that shows the problem.  you'll have to adjust the URL's to
match your configuration.

======== frameset.html ==========
<html>

<frameset rows="40,*,68" frameborder="0" framespacing="0" border="0">

<frame src="file://s:/testcases/pages/hotwired/test.html" scrolling="no"
marginheight="1" marginwidth="1">

<frame src="file://s:/testcases/pages/hotwired/test.html" scrolling="yes"
marginheight="1" marginwidth="1">
<frame src="file://s:/testcases/pages/hotwired/test.html" scrolling="no"
marginheight="1" marginwidth="1">

</frameset>

</html>

======== test.html ==========
<html><head>

</head>

<body>

test
<br><img
src="http://static.wired.com/advertising/blipverts/music_blvd/gc120.gif"
BORDER=1 height=60 width=120 alt="Click here for Music Blvd">
<TABLE nowrap cellpadding="2" cellspacing="0" border="0" width="600" border>
<TR align="center">
<TD valign="top" align="left">
<img
src="http://static.wired.com/advertising/blipverts/sunmicrosystems/sun_dotcom_3_
tm.gif" BORDER=1 height=60 width=468 alt="Sun Microsystems.  We're the dot in
.com.">&nbsp;</TD>
<td valign="top" align="left">
<img src="http://static.wired.com/advertising/blipverts/music_blvd/gc120.gif"
BORDER=1 height=60 width=120 alt="Click here for Music Blvd"></td>
</TR>
</TABLE>

</body></html>
Status: NEW → ASSIGNED
petersen, could you please try testcase with latest build and verify ASAP.
Thanks!
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Fixed in viewer.exe with Dec 31 build under Windows NT and 95.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.