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.