Not sure what is correct component, sending to layout first. 1. Go to www.msn.com (or any P3P enabled site). 2. Open Page Info dialog and go to Privacy tab 3. Hit Summary button. 4. Click first statement link. Expected results: scroll to the statement Actual results: crash You need to apply the patch from bug 124503 to test this. This is a regression: this did not happen 2 days ago, probably didn't happen yesterday either (but not confirmed). A build where this works fine is available at: http://green.nscp.aoltw.net/heikki/mozilla-p3p-20020404.tgz (windows opt). This happens on Windows and Linux (at least), stack from Windows: NTDLL! 77fa018c() nsDebug::Assertion(const char * 0x02263bcc `string', const char * 0x02263c08 `string', const char * 0x02263c18 `string', int 650) line 291 + 13 bytes nsDebug::PreCondition(const char * 0x02263bcc `string', const char * 0x02263c08 `string', const char * 0x02263c18 `string', int 650) line 434 + 21 bytes nsCOMPtr<nsISHEntry>::operator->() line 650 + 34 bytes nsDocShell::InternalLoad(nsDocShell * const 0x04174a88, nsIURI * 0x0422fca0, nsIURI * 0x04175540, nsISupports * 0x00000000, int 1, const unsigned short * 0x0012fc40, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, unsigned int 2097153, nsISHEntry * 0x00000000, int 1, nsIDocShell * * 0x00000000, nsIRequest * * 0x00000000) line 4578 + 28 bytes nsWebShell::OnLinkClickSync(nsWebShell * const 0x04174bcc, nsIContent * 0x042397e8, nsLinkVerb eLinkVerb_Replace, const unsigned short * 0x04179580, const unsigned short * 0x100b6ba4 gCommonEmptyBuffer, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, nsIDocShell * * 0x00000000, nsIRequest * * 0x00000000) line 619 + 91 bytes OnLinkClickEvent::HandleEvent() line 462 HandlePLEvent(OnLinkClickEvent * 0x041794e8) line 476 PL_HandleEvent(PLEvent * 0x041794e8) line 596 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x011f4d90) line 526 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00250218, unsigned int 49455, unsigned int 0, long 18828688) line 1077 + 9 bytes USER32! 77e11b60() USER32! 77e11cca() USER32! 77e183f1() nsAppShellService::Run(nsAppShellService * const 0x016a45a8) line 309 main1(int 2, char * * 0x00284bd0, nsISupports * 0x00000000) line 1415 + 32 bytes main(int 2, char * * 0x00284bd0) line 1763 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e8d326()
16 years ago
Seems like radha changed this place yesterday, reassigning: /* save current position of scroller(s) (bug 59774) */ mOSHE->SetScrollPosition(cx, cy); <= mOSHE is null, CRASH here
I don't know the session history code so I don't know if this is going be good enough. Maybe there are other places where that same member needs to be guarded. The reason why we hit this place might be that the window and document are kind of unusual: the document was transformed with XSLT, and the window does not have scrollbars (that is another bug, but if that is fixed this bug might become hidden).
*** Bug 135755 has been marked as a duplicate of this bug. ***
This fix should be ok for bug #135755, assuming one cannot navigate back in history when reading HTML mail. Is this assumption correct?
Created attachment 78245 [details] [diff] [review] patch v 1.1 This patch is pretty much the same as the one before. It also takes care of the tab issues I forgot(docshell uses 4 spaces for tabs) when I fixed bug 59774.
Comment on attachment 78245 [details] [diff] [review] patch v 1.1 r=mcafee
Comment on attachment 78245 [details] [diff] [review] patch v 1.1 firstname.lastname@example.org
Does this cover all of the crashes at nsDocShell::InternalLoad that have been reported in talkback starting in 2002-04-05 builds? User comments are: (4975521) Comments: clashed when I clicked on one of the spoofing UA string choices. (4974362) Comments: clicking link for info on davis cup (4959313) URL: www.winamp.com (4959313) Comments: reading e-mail via IMAP (4957976) URL: https://akoim1.us.army.mil/login.cfm (4957976) Comments: Was using Google Groups in a multiple tab situation and clicked a link on left frame of google group frameset to switch messages (4951999) URL: ftp://ftp.ipswitch.com/ (4946360) URL: www.mozilla.org (4946360) Comments: I sent a Mail then switched to the (so far empty) browser window and selected www.mozilla.org from my bookmarks. Turned back to mail part and read a mail while the page was loading. Without any special action the browser crashed. (4943922) URL: chrome://navigator/content/navigator.xul (4886217) URL: http://www.dnalounge.com/backstage/log/2002/04.html#4-apr-2002 (4886217) Comments: Hmm. Crash has nothing to do with Jamie's DNA Lounge sidebar. Bottom line is clicking on "details" link in MozGuest sidebar crashes my moz. (4886127) URL: http://www.dnalounge.com/backstage/log/2002/04.html#4-apr-2002 (4886127) Comments: Added DNA Lounge sidebar created by Jamie Zawinski. Then hid it. The MozGuest sidebar appeared. Clicked the "details" link at the top of the MozGuest sidebar. Boom -- crashed with "DNA Lounge" mentioned in the crash message. First time moz has crashed on (4886127) Comments: me in yonks... (4874291) URL: http://www.golfinfo.at/test/start.asp (4874291) Comments: Clicked kontakt. (4870088) Comments: bug 135755 click anchor link in mail message (4869882) Comments: clicked on anchor link in mail message (4869766) Comments: clicked on anchor link in mail message and the stacks look the same.
Making topcrash+..this is definitely a topcrasher and a regression that started showing up in 4/5 MozillaTrunk builds.
adt1.0.0+ (on behalf of the adt)
Fix checked in.
Fixed checked in to MOZILLA 1.0 branch too.
16 years ago
Confirming that duplicate bug 135755 is fixed by this checkin on Windows NT.
Build: 2002-04-23-08-1.0.0(WIN NT/98), 2002-04-23-08-1.0.0(LINUX), 2002-04-23-05-1.0.0(MAC) Clicking on Site Statement 1 link displays page as expected. No crash. Adding verified1.0.0 keyword. From TRUNK, the behavior is different. Upon displaying the Summary, the Site Statement links are not URLs or do not appear to be. Clicking on the link does not crash, but the summary does not appear. Can somebody explain this? Waiting for comments about TRUNK build difference. Leaving bug in RESOLVED state for now.
OK. Today's trunk builds (4/26/02) look good now. Links are present. Marking Verified for TRUNK.