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

VERIFIED FIXED in M11

Status

()

P3
critical
VERIFIED FIXED
19 years ago
2 months ago

People

(Reporter: sspitzer, Assigned: harishd)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [TESTCASE], URL)

Attachments

(2 attachments)

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.

Updated

19 years ago
Assignee: don → dp
Severity: normal → critical
Component: Browser-General → XPCOM
Whiteboard: [TESTCASE]

Comment 2

19 years ago
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.

Updated

19 years ago
Assignee: dp → rickg

Comment 3

19 years ago
Rick this is either string or layout. Either way, your I think. Let me know if
not.

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 4

19 years ago
This is non-reproducable on NT or mac. I'll try my linux box this evening.

Comment 5

19 years ago
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

Updated

19 years ago
Assignee: rickg → pollmann
Status: ASSIGNED → NEW

Comment 7

19 years ago
Eric -- this looks like a frame bug to me. The content model is very wrong here.

Updated

19 years ago
Assignee: pollmann → harishd
Component: XPCOM → HTMLFrames

Comment 8

19 years ago
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.

Comment 9

19 years ago
Created attachment 1778 [details]
Original test case (added href base)

Comment 10

19 years ago
Created attachment 1779 [details]
Fixed test case (base href added, dtd decl removed)
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M11
(Assignee)

Comment 11

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 12

19 years ago
Checked in a fix.

Comment 13

19 years ago
Resetting QA contact from leger.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 14

19 years ago
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.

Updated

2 months ago
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.