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

VERIFIED FIXED in mozilla1.0



17 years ago
8 years ago


(Reporter: hjtoi-bugzilla, Assigned: radha)


({crash, regression, topcrash+})

crash, regression, topcrash+

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [ADT1] ETA 4/9/02, crash signature, URL)


(1 attachment, 1 obsolete attachment)

Not sure what is correct component, sending to layout first.

1. Go to (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: (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()
Blocks: 124503
Keywords: crash, nsbeta1+
Whiteboard: [ADT1]
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
Assignee: attinasi → radha
Component: Layout → History: Session
Keywords: regression
QA Contact: petersen → claudius
Created attachment 77987 [details] [diff] [review]
Null pointer check seems to fix this for me
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. ***

Comment 5

17 years ago
This fix should be ok for bug #135755, assuming one cannot navigate back in
history when reading HTML mail. Is this assumption correct?
Target Milestone: --- → mozilla1.0
Whiteboard: [ADT1] → [ADT1] ETA 4/9/02
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.
Attachment #77987 - Attachment is obsolete: true

Comment 7

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

Attachment #78245 - Flags: review+

Comment 8

17 years ago
Comment on attachment 78245 [details] [diff] [review]
patch v 1.1
Attachment #78245 - Flags: superreview+
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:
     (4959313)	Comments: reading e-mail via IMAP
     (4957976)	URL:
     (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:
     (4946360)	URL:
     (4946360)	Comments: I sent a Mail  then switched to the (so far empty) browser window
and selected from my bookmarks. Turned back to mail part and
read a mail while the page was loading. Without any special action the browser
     (4943922)	URL: chrome://navigator/content/navigator.xul
     (4886217)	URL:
     (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:
     (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:
     (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.
Keywords: topcrash
Summary: Crash when trying to follow internal link in P3P summary window → Crash when trying to follow internal link in P3P summary window [@ nsDocShell::InternalLoad]


17 years ago
Attachment #78245 - Flags: approval+
Keywords: adt1.0.0

Comment 10

17 years ago
Making topcrash+..this is definitely a topcrasher and a regression that started
showing up in 4/5 MozillaTrunk builds.
Keywords: topcrash → topcrash+

Comment 11

17 years ago
adt1.0.0+ (on behalf of the adt)
Keywords: adt1.0.0 → adt1.0.0+
Fix checked in.
Last Resolved: 17 years ago
Resolution: --- → FIXED
Fixed checked in to MOZILLA 1.0 branch too.
Keywords: fixed1.0.0

Comment 14

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

Comment 15

17 years ago
Build: 2002-04-23-08-1.0.0(WIN NT/98), 2002-04-23-08-1.0.0(LINUX),

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.
Keywords: fixed1.0.0 → verified1.0.0
QA Contact: claudius → jimmylee

Comment 16

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


10 years ago
Component: History: Session → Document Navigation
QA Contact: jimmykenlee → docshell
Crash Signature: [@ nsDocShell::InternalLoad]
You need to log in before you can comment on or make changes to this bug.