Easy to reproduce (did it 5 five times in a row to get the simplest way): 1) Start Mozilla M14 2) Edit the URL to be "http://slashdot.org" and press enter. 3) When the page has loaded, hold down right mousebutton over the page somewhere with no text. 4) The menu with "Back" listed topmost appears. Release the right mousebutton over "Back". The menu stays up and nothing happens except "Back" is highlighted. Click somewhere else outside the menu and with no links to get rid of the menu. (another bug, but I know that is scheduled for M15). I can't get it to crash without step 3 and 4 though. Don't know why. 5) Scroll the page down (I use the slider to the right) so that the slashdot poll is accesible. 6) Press the "Results" link next to the "Vote" button. 7) Crash. Since the slashdot.org content changes I don't know if this will keep happening... :( But today it did, March 3rd 2000, 16.05 GMT

Browsing on, this can happen on just about any website if steps (3) and (4) are done or repeated some times. Browsing works for a long time, but as soon as the right mousebutton menu is used, it crashed soon after. M13 never did this AFAIK.

Slashdot's contents have changed in a way that doesn't produce the bug anymore. So far, I have been unsuccessful in finding a simple website that does this. I still have a site that does it every time: http://www.ibm.com Go there, do steps (3) and (4) exactly, then press "Products" => crash. I will try to destill this method as much as I can.

reporoter - cannot reproduce on m15 nightly. Can you please download a m15 ngihtly (on the main page of mozilla.org) and see if oyu can reproduce? remember to delete the old mozilla files. thanks

With the nightly M15 build 2000030516, I can't reproduce this bug anymore. Thank you very much.

marking worksforeme on m15 build. Probably a dupe of a fixed bug, if it reappears, will look into it.

Oh no! I recreated the problem with nightly build 2000031215: 1) Go to http://soundworks.dk and wait for it to load 2) Click on "Profile" at the bottom left and wait for that to load 3) Click the right mousebutton and choose "Back" 4) Crash Did it five times in a row.

reopening, can crash on this. cbegle - any idea for a component? this couls be frames related, as the site uses frames. Could be possibly related to bug 28142, back button in frames icky. my guess is that it tries to go back in a frame, but it should go back for the entire page...

using the steps noted by j.frandsen: ###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ..\ ..\..\dist\include\nsCOMPtr.h, line 591 after i ignore the assert, i crash. stack trace: nsHistoryEntry::Load(nsIWebShell * 0x038627a8, int 0) line 549 + 54 bytes nsHistoryEntry::Load(nsIWebShell * 0x03055a98, int 0) line 653 + 25 bytes nsHistoryEntry::Load(nsIWebShell * 0x02eb9238, int 0) line 653 + 25 bytes nsHistoryEntry::Load(nsIWebShell * 0x02e69ab8, int 0) line 653 + 25 bytes nsSessionHistory::Add(nsSessionHistory * const 0x02e711b0, const char * 0x03863c80, const char * 0x0012deac, nsIWebShell * 0x038627a8) line 934 + 17 bytes nsWebShell::LoadURL(nsWebShell * const 0x038627a8, const unsigned short * 0x03861080, const char * 0x00390658, nsIInputStream * 0x00000000, int 1, unsigned int 0, const unsigned int 0, nsISupports * 0x00000000, const unsigned short * 0x00000000, const char * 0x00000000) line 1737 + 95 bytes nsWebShell::LoadURL(nsWebShell * const 0x038627a8, const unsigned short * 0x03861080, nsIInputStream * 0x00000000, int 1, unsigned int 0, const unsigned int 0, nsISupports * 0x00000000, const unsigned short * 0x00000000) line 993 nsWebShell::LoadURI(nsWebShell * const 0x038626cc, const unsigned short * 0x03861080) line 1304 nsHTMLFrameInnerFrame::Reflow(nsHTMLFrameInnerFrame * const 0x02538f24, nsIPresContext * 0x03376580, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 54066904) line 911 nsContainerFrame::ReflowChild(nsIFrame * 0x02538f24, nsIPresContext * 0x03376580, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 54066904) line 646 + 31 bytes nsHTMLFrameOuterFrame::Reflow(nsHTMLFrameOuterFrame * const 0x02538e70, nsIPresContext * 0x03376580, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 54066904) line 377 nsContainerFrame::ReflowChild(nsIFrame * 0x02538e70, nsIPresContext * 0x03376580, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 54066904) line 646 + 31 bytes nsHTMLFramesetFrame::ReflowPlaceChild(nsIFrame * 0x02538e70, nsIPresContext * 0x03376580, const nsHTMLReflowState & {...}, nsPoint & {...}, nsSize & {...}, nsPoint * 0x0012e928) line 815 nsHTMLFramesetFrame::Reflow(nsHTMLFramesetFrame * const 0x02538d9c, nsIPresContext * 0x03376580, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 1177 nsBlockReflowContext::ReflowBlock(nsIFrame * 0x02538d9c, const nsRect & {...}, int 1, int 0, int 1, nsMargin & {...}, unsigned int & 0) line 449 + 45 bytes nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineBox * 0x02538e48, int * 0x0012eefc) line 3538 + 59 bytes nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x02538e48, int * 0x0012eefc, int 0) line 2851 + 23 bytes nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2658 + 27 bytes nsBlockFrame::Reflow(nsBlockFrame * const 0x02538d50, nsIPresContext * 0x03376580, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 1577 + 15 bytes nsAreaFrame::Reflow(nsAreaFrame * const 0x02538d50, nsIPresContext * 0x03376580, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 272 + 25 bytes nsContainerFrame::ReflowChild(nsIFrame * 0x02538d50, nsIPresContext * 0x03376580, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 646 + 31 bytes RootFrame::Reflow(RootFrame * const 0x02538d14, nsIPresContext * 0x03376580, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 331 nsContainerFrame::ReflowChild(nsIFrame * 0x02538d14, nsIPresContext * 0x03376580, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 646 + 31 bytes ViewportFrame::Reflow(ViewportFrame * const 0x02538cd8, nsIPresContext * 0x03376580, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 531 PresShell::InitialReflow(PresShell * const 0x0338eb90, int 13380, int 7530) line 1282 HTMLContentSink::StartLayout() line 3063 HTMLContentSink::CloseFrameset(HTMLContentSink * const 0x03373800, const nsIParserNode & {...}) line 2848 CNavDTD::CloseFrameset(const nsIParserNode * 0x0338c630) line 2829 + 31 bytes CNavDTD::CloseContainer(const nsIParserNode * 0x0338c630, nsHTMLTag eHTMLTag_frameset, int 0) line 2996 + 12 bytes CNavDTD::CloseContainersTo(int 1, nsHTMLTag eHTMLTag_frameset, int 0) line 3041 + 20 bytes CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_frameset, int 0) line 3209 + 20 bytes CNavDTD::HandleEndToken(CToken * 0x02eb8700) line 1642 + 20 bytes CNavDTD::HandleToken(CNavDTD * const 0x0338b040, CToken * 0x02eb8700, nsIParser * 0x03373b00) line 770 + 12 bytes CNavDTD::BuildModel(CNavDTD * const 0x0338b040, nsIParser * 0x03373b00, nsITokenizer * 0x0338a650, nsITokenObserver * 0x00000000, nsIContentSink * 0x03373800) line 504 + 20 bytes nsParser::BuildModel() line 1286 + 34 bytes nsParser::ResumeParse(int 1, int 0) line 1171 + 11 bytes nsParser::OnDataAvailable(nsParser * const 0x03373b04, nsIChannel * 0x03b59320, nsISupports * 0x00000000, nsIInputStream * 0x03b5a0b0, unsigned int 0, unsigned int 507) line 1581 + 19 bytes nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x03b59900, nsIChannel * 0x03b59320, nsISupports * 0x00000000, nsIInputStream * 0x03b5a0b0, unsigned int 0, unsigned int 507) line 267 + 46 bytes nsHTTPCacheListener::OnDataAvailable(nsHTTPCacheListener * const 0x03b5bb10, nsIChannel * 0x03b5bce0, nsISupports * 0x00000000, nsIInputStream * 0x03b5a0b0, unsigned int 0, unsigned int 507) line 180 AsyncReadStreamAdaptor::OnDataAvailable(AsyncReadStreamAdaptor * const 0x03b5a0b4, nsIChannel * 0x03b5bce0, nsISupports * 0x00000000, nsIInputStream * 0x03b5a0b0, unsigned int 0, unsigned int 507) line 109 + 49 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x03b5c690) line 384 + 47 bytes nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03b5c640) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x03b5c640) line 563 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00ffc040) line 508 + 9 bytes _md_EventReceiverProc(HWND__ * 0x20b903f6, unsigned int 49335, unsigned int 0, long 16760896) line 1018 + 9 bytes USER32! 77e71268() 00ffc040()

updating status

This has got to be a dup ...

M16.

norris checked in a fix for this couple of weeks ago. I belive this s'd be fixed now. Can some one verify?

I cannot see this with newbuilds reporter - if with new build you still see this, please reopen.

what combination of build/testcase have you tried this with? I am unable to verify this bug because I haven't found a combination that's truly testable. AND context menus don't work.

This still happens with the 2000040610 builds on WinNT. I tried at www.ibm.com following the - j.frandsen@visionik.dk 2000-03-06 04:10 ------- comments. For those tryingto reproduce, read step 3 very carefully (don't let go of the right mouse button)

claudius - are you crashing? i can't seem to reproduce a crash

actually i crash quite easily doing now. Bring up a context menu. Click away to dismiss it and then click that proucts link on the ibm site = boom. i get a totaly different stack trace though than the one entered here previously. MSVCRT.dll + 0x1637 (0x78001637) nsByteArrayInputStream::Read [d:\builds\seamonkey\mozilla\xpcom\io\nsByteArrayInputStream.cpp, line 73] InterceptStreamListener::Read [d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCachedNetData.cpp, line 1142] nsParser::OnDataAvailable [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1566] nsDocumentOpenInfo::OnDataAvailable [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 271] InterceptStreamListener::OnDataAvailable [d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCachedNetData.cpp, line 1129] nsHTTPChunkConv::OnDataAvailable [d:\builds\seamonkey\mozilla\netwerk\streamconv\converters\nsHTTPChunkConv.cpp, line 197] nsHTTPServerListener::OnDataAvailable [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 427] nsOnDataAvailableEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 412] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 106] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 564] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1020] USER32.dll + 0x1268 (0x77e71268)

claudius - you simple rmb somewhere not with text, dismiss it, click products and it crashes? i cannot reproduce on win98, could be winnt specific.

I crashed it today with 2000041009 builds on WinNT and Win98, using the simple procedure you just mentioned

Reproduced (www.ibm.com) with PC/Linux. Results: M14 always crashes 2000-04-07-08-M15: always crashes (after repeated clicking on "Products") 2000-04-10-08-M15: always crashes (after repeated clicking on "Products") 2000-04-12-12-M15: never crashes 2000-04-14-12-M15: never crashes 2000-04-15-05-M15: never crashes 2000-04-14-09-M16: never crashes It seems that this has been fixed between 4/10 and 4/12. Please resolve and verifyme.

Bug 35881 could be related.

35881 is a dupe of a bug that has to do with resize after reload. doubt that it is related. Are you still crashing on say m15 or a m16 nightly?

I'm reevaluating this bug in light of the recent changes to Webshell and SH and while the behavior has changed, this bug is still valid. I used the testcase outlined with the www.ibm.com page [Additional Comments From j.frandsen@visionik.dk 2000-03-06 04:10] On windows, clicking the product link yields nothing, the borwser spins and eventually times out, the page is never loaded. On Mac, this was a little harder to reproduce (because mouseup over 'back' actually fires the command) so I moused up over a greyed out command. Clicking the 'product' link resulted in a crash.

What you see here is pretty much the same stack trace as bug 37178: "Crash in nsScanner::~nsScanner when visiting Japanese web pages". Since the original crashes in this bug were all in nsByteArrayInputStream::Read, I'd suggest to check this bug again once that bug is fixed. Marking dependency.

FYI, for me (the reporter), it still crashes on http://www.ibm.com Just right-click (and hold down) on the page (somewhere empty) and release over "Back". Then go outside the context-menu and click there with the left button to dismiss the context menu. Then click on "Products" => crash.

Sorry, forgot to include the version number. I used the nightly build 2000042512

See my comments in bug 37178. I can confirm that build 2000042512 crashes, but any other build seems to work fine, e.g. 2000042609. I also agree that this is a very useful testcase :) Adding myself to CC.

Jakob, can this bug be closed? PC/Linux build 2000052109 works fine, too.

Nightly build 2000052320 won't even let me go to http://www.ibm.com without crashing, so I can't confirm that this bug is fixed. :(

Move to M20 target milestone.

Still can't confirm the bug as fixed. Nightly build 2000060720 still crashes when attempting to go to http://www.ibm.com Is this what other people see?

Finally, build 2000061520 doesn't crash when loading http://www.ibm.com/ so I was able to perform the test and this build works fine - I tried hard, but couldn't get it to crash... as far as I'm concerned, the bug is resolved.

as per the last comment

VERIFIED Fixed in 2000113004 builds