135868 - Crash when trying to follow internal link in P3P summary window [@ nsDocShell::InternalLoad]

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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()

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Null pointer check seems to fix this for me

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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).

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 5

[Miloslaw Smyk]

This fix should be ok for bug #135755, assuming one cannot navigate back in
history when reading HTML mail. Is this assumption correct?

Comment 6

[Radha on family leave (not reading bugmail)]

Attachment: 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 7

[Chris McAfee]

Comment on attachment 78245 [details] [diff] [review]
patch v 1.1

r=mcafee

Comment 8

[rpotts (gone)]

Comment on attachment 78245 [details] [diff] [review]
patch v 1.1

sr=[e-mail]

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 10

[Jay Patel [:jay]]

Making topcrash+..this is definitely a topcrasher and a regression that started
showing up in 4/5 MozillaTrunk builds.

Comment 11

[Paul Wyskoczka]

adt1.0.0+ (on behalf of the adt)

Comment 12

[Radha on family leave (not reading bugmail)]

Fix checked in.

Comment 13

[Radha on family leave (not reading bugmail)]

Fixed checked in to MOZILLA 1.0 branch too.

Comment 14

[Aleksander Adamowski]

Confirming that duplicate bug 135755 is fixed by this checkin on Windows NT.

Comment 15

[Jimmy Lee]

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.

Comment 16

[Jimmy Lee]

OK.  Today's trunk builds (4/26/02) look good now.  Links are present.  Marking
Verified for TRUNK.