Mozilla will crash when opening the problem URL if Javascript is disabled and if cookies are denied. How to reproduce: 0. Close any unsaved work. 1. Disable Javascript in Navigator. 2. Set browser to prompt for each cookie. (I'm unsure whether this is necessary) 3. Open <http://www.nocom.se/press/pageDisplay.jsp?page_id=153>. 4. Deny incoming cookie. Expected result: The page should load fine. Actual result: The browser crashes with signal 11 on my Linux box, or with a Windows GPF. On Windows, it seems that accepting the cookie causes the browser to hang indefinitely. The problem 100 % reproducible for me. Tested in: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020627. Also seen in Netscape 7.0 PR1 and in Mozilla 0.9.9, both on Windows 98. I cannot reproduce in Netscape 6.2.1 on Linux, nor in K-Meleon 0.6.

working on testcase.

Do you have a talkback ID from that crash ?

This is as minimal as I could get it.

so you can view source without crashing

For my testcase, javascript does NOT need to be disabled, nor do cookies. Notice the link tag outside of the head, if it is moved into the head, no crash. if it is removed, no crash. That's where it is in the original page that doesn't crash if you have javascript enabled.

Example provided in Comment #5 also crashes Mozilla 1.0 Build 2002053012 on Win2k, with or without disabling cookies/javascript.

i crash with the testcase.. nsQueryInterface::operator()(const nsID & {...}, void * * 0x0012f4bc) line 47 + 23 bytes nsCOMPtr<nsIBox>::assign_from_helper(const nsCOMPtr_helper & {...}, const nsID & {...}) line 922 + 18 bytes nsCOMPtr<nsIBox>::nsCOMPtr<nsIBox>(const nsQueryInterface & {...}) line 566 nsCSSFrameConstructor::StyleChangeReflow(nsIPresContext * 0x041efd08, nsIFrame * 0x04158110, nsIAtom * 0x00000000) line 10183 nsCSSFrameConstructor::ProcessRestyledFrames(nsCSSFrameConstructor * const 0x041e4078, nsStyleChangeList & {...}, nsIPresContext * 0x041efd08) line 10320 PresShell::ReconstructStyleData(PresShell * const 0x041e9c18, int 0) line 5530 PresShell::StyleSheetAdded(PresShell * const 0x041e9c20, nsIDocument * 0x04024660, nsIStyleSheet * 0x03b488b8) line 5550 nsDocument::InsertStyleSheetAt(nsDocument * const 0x04024660, nsIStyleSheet * 0x03b488b8, int 0, int 1) line 1633 CSSLoaderImpl::InsertSheetInDoc(nsICSSStyleSheet * 0x03b488b8, int 0, nsIContent * 0x0414c880, int 1, nsICSSLoaderObserver * 0x00000000) line 1206 CSSLoaderImpl::SheetComplete(nsICSSStyleSheet * 0x03b488b8, SheetLoadData * 0x0414cd98) line 909 CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x03ee4030, SheetLoadData * 0x0414cd98, int & 1, nsICSSStyleSheet * & 0x03b488b8) line 964 CSSLoaderImpl::DidLoadStyle(nsIStreamLoader * 0x0414cfa0, nsString * 0x03c83fd0, SheetLoadData * 0x0414cd98, unsigned int 0) line 999 + 27 bytes SheetLoadData::OnStreamComplete(SheetLoadData * const 0x0414cd98, nsIStreamLoader * 0x0414cfa0, nsISupports * 0x00000000, unsigned int 0, unsigned int 7152, const char * 0x03d7efb0) line 756 nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x0414cfa4, nsIRequest * 0x0414cff8, nsISupports * 0x00000000, unsigned int 0) line 163 nsStreamListenerTee::OnStopRequest(nsStreamListenerTee * const 0x03d1be90, nsIRequest * 0x0414cff8, nsISupports * 0x00000000, unsigned int 0) line 66 nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x0414cffc, nsIRequest * 0x03d7e16c, nsISupports * 0x00000000, unsigned int 0) line 2915 nsOnStopRequestEvent::HandleEvent() line 213 nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x0312824c) line 116 PL_HandleEvent(PLEvent * 0x0312824c) line 596 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x01033cf8) line 526 + 9 bytes _md_EventReceiverProc(HWND__ * 0x003103b8, unsigned int 49406, unsigned int 0, long 16989432) line 1077 + 9 bytes USER32! 77e01b60() USER32! 77e01cca() USER32! 77e083f1() nsAppShellService::Run(nsAppShellService * const 0x0159b600) line 458 main1(int 2, char * * 0x00283160, nsISupports * 0x00000000) line 1456 + 32 bytes main(int 2, char * * 0x00283160) line 1805 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e7d326() -> Layout

Might as well change this to NEW...

the empty <table> can be other things (like <p></p>). it will still crash.

resummarizing

I'm still seeing the same problem, but only with scripting disabled. Re comment #2: I don't have Talkback enabled. Since the problem seems to be reproducible, I don't think you need that information from me. Tested in rv:1.1a+, Gecko/20020704.

this crash is very serious as it crashes entire sprocket client. adding talkback team. requesting qa assistance and adding marek. am looking into talkback info...

Kevin : Who will be right person to work on this bug ?

The crash bug is still there, in "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016". I have a talkback ID from crash when trying to open attachment #89657 [details]: TB12726868Y.

Bug 178358 is a dupe of this, I think.

*** Bug 178358 has been marked as a duplicate of this bug. ***

Patch in bug 123049 fixes this too.

Right, bug 123049 seems to have fixed this, at least there is no crash with the testcases here (original URL + testcases, also with JS disabled) with 2003012005 on Win2k. -> Fixed? (What about all the other bugs bug 123049 was supposed to fix? They are still open.)

2003012008/MacOS9 doesn't crash now.

-> fixed