Closed Bug 13498 Opened 25 years ago Closed 25 years ago

http://www.topica.com loads, but doesn't display

Categories

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

x86
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sspitzer, Assigned: harishd)

References

()

Details

(Whiteboard: [TESTCASE])

Attachments

(2 files)

9-9-99 linux build. go to http://www.topica.com causes a crash, every time. #0 0x4011e994 in CompressChars2 (aString=0x4016d464 "", aLength=0, aSet=0x4016d50d "\b\t\r\n ") at bufferRoutines.h:717 #1 0x4011f22b in nsStr::CompressSet (aDest=@0x8923608, aSet=0x4016d50d "\b\t\r\n ", aEliminateLeading=1, aEliminateTrailing=1) at nsStr.cpp:336 #2 0x40123808 in nsString::CompressSet (this=0x8923608, aSet=0x4016d50d "\b\t\r\n ", aChar=32, aEliminateLeading=1, aEliminateTrailing=1) at nsString2.cpp:524 #3 0x40123845 in nsString::CompressWhitespace (this=0x8923608, aEliminateLeading=1, aEliminateTrailing=1) at nsString2.cpp:543 #4 0x40e23009 in HTMLContentSink::SetTitle (this=0x88f03e0, aValue=@0x8922db4) at nsHTMLContentSink.cpp:1839 #5 0x4059f227 in CNavDTD::AddHeadLeaf (this=0x89232f8, aNode=@0x8922da0) at CNavDTD.cpp:2702 #6 0x4059c3e9 in CNavDTD::HandleStartToken (this=0x89232f8, aToken=0x82aa0f8) at CNavDTD.cpp:1295 #7 0x4059a13d in NavDispatchTokenHandler (aToken=0x82aa0f8, aDTD=0x89232f8) at CNavDTD.cpp:241 #8 0x405abdf4 in CTokenHandler::operator() (this=0x8923460, aToken=0x82aa0f8, aDTD=0x89232f8) at nsTokenHandler.cpp:80 #9 0x4059b350 in CNavDTD::HandleToken (this=0x89232f8, aToken=0x82bf960, aParser=0x88c8778) at CNavDTD.cpp:740 #10 0x4059ac6e in CNavDTD::BuildModel (this=0x89232f8, aParser=0x88c8778, aTokenizer=0x8919b28, anObserver=0x0, aSink=0x88f03e0) at CNavDTD.cpp:551 #11 0x405a8c1c in nsParser::BuildModel (this=0x88c8778) at nsParser.cpp:942 #12 0x405a8acc in nsParser::ResumeParse (this=0x88c8778, aDefaultDTD=0x0, aIsFinalChunk=0) at nsParser.cpp:887 #13 0x405a954f in nsParser::OnDataAvailable (this=0x88c8778, channel=0x8636050, aContext=0x0, pIStream=0x8919460, sourceOffset=0, aLength=483) at nsParser.cpp:1286 #14 0x40ab7f22 in nsDocumentBindInfo::OnDataAvailable (this=0x86a6168, channel=0x8636050, ctxt=0x0, aStream=0x8919460, sourceOffset=0, aLength=483) at nsDocLoader.cpp:1985 #15 0x40ab8b94 in nsChannelListener::OnDataAvailable (this=0x8636170, aChannel=0x8636050, aContext=0x0, aInStream=0x8919460, aOffset=0, aCount=483) at nsDocLoader.cpp:2257 #16 0x41d1a2ef in nsHTTPResponseListener::OnDataAvailable (this=0x88dd8b0, channel=0x861a9c0, context=0x8636050, i_pStream=0x8919460, i_SourceOffset=0, i_Length=483) at nsHTTPResponseListener.cpp:186 #17 0x4095f527 in nsOnDataAvailableEvent::HandleEvent (this=0x41e00eb0) at nsAsyncStreamListener.cpp:344 #18 0x4095ed83 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x41e00eb0) at nsAsyncStreamListener.cpp:144 #19 0x4018029b in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/libplds3.so #20 0x401801ac in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/libplds3.so #21 0x40148d4d in nsEventQueueImpl::ProcessPendingEvents (this=0x806ed58) at nsEventQueue.cpp:118 #22 0x4053d5c6 in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/libwidget_gtk.so #23 0x4071c789 in ?? () from /usr/lib/libgdk-1.2.so.0 #24 0x40748d6a in ?? () from /usr/lib/libglib-1.2.so.0 #25 0x4074a2c6 in ?? () from /usr/lib/libglib-1.2.so.0 #26 0x4074a801 in ?? () from /usr/lib/libglib-1.2.so.0 #27 0x4074a979 in ?? () from /usr/lib/libglib-1.2.so.0 #28 0x40679f3a in ?? () from /usr/lib/libgtk-1.2.so.0 #29 0x4053dd99 in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/libwidget_gtk.so #30 0x403a9661 in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/libnsappshell.so #31 0x804b138 in main1 (argc=1, argv=0xbffffab4) at nsAppRunner.cpp:836 #32 0x804b245 in main (argc=1, argv=0xbffffab4) at nsAppRunner.cpp:859 #33 0x4027ecb3 in ?? () from /lib/libc.so.6
OS: Linux → All
marking all. it crashes on windows as well.
Assignee: don → dp
Severity: normal → critical
Component: Browser-General → XPCOM
Whiteboard: [TESTCASE]
I have tracked down the frame that causes this. Turns out it's completly empty of any content. Here is a simplified testcase: <HTML> <HEAD><TITLE></TITLE></HEAD> <BODY></BODY> </HTML> I think the empty TITLE is causing the crash (invalid page fault in module XPCOM.DLL), leading to nsString::CompressWhitespace on an empty string. I think this could be a serious problem so I am going to be bold enough to raise severity and reassign to XPCOM. BTW, I tested using apprunner 1999-09-10-10-M11 on Windows 98.
Assignee: dp → rickg
Rick this is either string or layout. Either way, your I think. Let me know if not.
Status: NEW → ASSIGNED
This is non-reproducable on NT or mac. I'll try my linux box this evening.
It doesn't crash apprunner 1999-09-17-13-M11 on Windows 98 either.
Summary: http://www.topica.com causes a crash → http://www.topica.com loads, but doesn't display
it doesn't crash for me on linux any more. but it does fail to display. when I go to http://www.topica.com, it appears to load the page, but fails to render it. (it comes up blank) changing url back to http://www.topica.com
Assignee: rickg → pollmann
Status: ASSIGNED → NEW
Eric -- this looks like a frame bug to me. The content model is very wrong here.
Assignee: pollmann → harishd
Component: XPCOM → HTMLFrames
Hmm, the content model being formed incorrectly is exactly why I'd say the bug was in parser/content sink area - if we don't get frameset/frames content, we can't get corresponding frames. From dumping the content model of this document in viewer, it looks like a body tag is being opened when a frameset should be opened instead. I got this bug to go away by removing the very first line of the file. The first line is: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> I tried replacing this with the strict and frameset DTD lines, but the result was also no rendering. Harish, can you take a look at this bug and figure out why not frame/frameset content is created? I'm attaching the original, then my 'fixed' test case.
Attached file Original test case (added href base) (deleted) —
Status: NEW → ASSIGNED
Target Milestone: M11
My bad ( very bad..uuucckkk). After differntiating DOCTYPE from comment I stupidly allowed DOCTYPE token to pass through misplace-content handling code. In doing so, the DOCTYPE token opened up a BODY and therefore did not open FRAMESET/FRAME.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Checked in a fix.
Resetting QA contact from leger.
Status: RESOLVED → VERIFIED
The problem is not occuring with the Nov 19th build on Windows 98 and Linux Red Hat 6.0 or on the Nov 17th Mac OS 9.0 build. Marking verified fixed.
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.

Attachment

General

Creator:
Created:
Updated:
Size: