58843 - N601 crash #7 [@ DocumentViewerImpl::MakeWindow]; triggered from xul for 'understanding privacy'

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[John Morrison]

Overview Description: 
  There is a consistent crash that is setup by viewing the 
  Understanding Privacy xul window and getting a http: URL
  to load into its content area. Once that has occurred, I 
  believe that the user is walking on thin ice. 

  Here's a reliable set of steps.

Steps to Reproduce: 

1) Tasks -> Privacy and Security -> Understanding Privacy
2) Help -> Feedback Center
3) Bookmarks -> How to Customize Bookmarks...
4) (2nd time) Tasks -> Privacy and Security -> Understanding Privacy

Actual Results:    crashes
Expected Results:  don't crash

Reproducibility:  100%

Build Date & Platform Bug Found: 
  2000110109 linux/mac/win32


"Giving" this to morse, but the crash is in webshell/docshell/docviewer
stuff, but I don't know who owns that these days.


Here are the messages in the Windows console, beginning with step one
and leading to the crash.

----------------------------------------
JavaScript error:
 line 0: uncaught exception: [Exception... "Component returned failure code: 
0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.sessionHistory]"  nsresult: 
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: 
chrome://communicator/content/help/help.js :: Initialize :: line 16"  
data: no]

Document chrome://communicator/content/help/help_security.xul loaded 
successfully
Error loading URL http://home.netscape.com/bookmark/6_0/bcustomize.html: 
804b0002
JavaScript error:
chrome://global/content/charsetOverlay.js line 191: window._content.document 
has no properties

Document http://home.netscape.com/bookmark/bestof/customize.html loaded 
successfully
----------------------------------------

Not sure if this is common enough to warrant a last-minute fix. 
Thoughts? (There are 7 talkback incidents recorded (not including me)
since Oct 23).

Here is the stack:

DocumentViewerImpl::MakeWindow 
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 1265] 
DocumentViewerImpl::Init 
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 545] 
nsDocShell::SetupNewViewer 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2928] 
nsWebShell::SetupNewViewer 
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 359] 
nsDocShell::Embed [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, 
line 2502] 
nsWebShell::Embed [d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, 
line 383] 
nsDocShell::CreateContentViewer 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2694] 
nsDSURIContentListener::DoContent 
[d:\builds\seamonkey\mozilla\docshell\base\nsDSURIContentListener.cpp, line 
104] 
nsDocumentOpenInfo::DispatchContent 
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 370] 
nsDocumentOpenInfo::OnStartRequest 
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 242] 
nsCachedChromeChannel::HandleStartLoadEvent 
[d:\builds\seamonkey\mozilla\rdf\chrome\src\nsChromeProtocolHandler.cpp, line 
515] 
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 581] 
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, 
line 517] 
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, 
line 1051] 
nsAppShellService::Run 
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 408] 
netscp6.exe + 0x1694 (0x00401694) 
netscp6.exe + 0x11b8 (0x004011b8) 
netscp6.exe + 0x2a4a (0x00402a4a) 
KERNEL32.DLL + 0x7903 (0x77e87903)

Comment 1

[John Morrison]

Oops. -> morse

Comment 2

[Stephen P. Morse]

Sounds like this is don's area.  cc'ing a few folks on this.  I certainly won't 
have time to look into it between now and rtm, so if this is important somebody 
else better pick it up.

Comment 3

[Blake Ross]

Are there any reproducible steps for those of us that don't have the commercial 
help you mentioned?

Comment 4

[John Morrison]

Not that I know of. You could likely distill a testcase by looking at the 
PR3 commercial bits, which may have had the same bug.

Comment 5

[Blake Ross]

darn.  I can't build commercial so that won't help me.  I wonder why I can't 
trigger this using other built-in links.

well, cc'ing some people about the window/docshell crash

Comment 6

[Blake Ross]

<reads closer> oh, distill a testcase; d'oh.  downloading pr3...

Comment 7

[Stephen P. Morse]

pr3 won't do it -- we didn't have vera's privacy document.  But you should be 
able to simulate it in the mozilla tree by making the same change that I made to 
get it into the commercial tree.  I'll look around shortly and find the 
directions for doing that.

Comment 8

[Stephen P. Morse]

In navigator.properties change

    wallet.TutorialFromMenu=chrome://communicator/locale/wallet/privacy.html
    wallet.TutorialFromPrefs=chrome://communicator/content/wallet/privacy.xul

to

   wallet.TutorialFromPrefs=chrome://communicator/content/help/help_security.xul
   wallet.TutorialFromMenu=chrome://communicator/content/help/help_security.xul

Then you will probably need the help_security.xul document as well so I'll 
attach it.

Comment 9

[Stephen P. Morse]

Attachment: help_security.xul

Comment 10

[Stephen P. Morse]

Of course to see that attachment you'll have to do view->page-source after you 
bring up the attachment.  I think I should have attached it as a text file 
rather than an html file and avoided this problem.  I'll try that.

Comment 11

[Stephen P. Morse]

Attachment: help_security.xul as a text file.

Comment 12

[Jay Patel [:jay]]

Adding topcrash keyword and [@ DocumentViewerImpl::MakeWindow] for tracking.
This is the #6 topcrasher for the official RTM build for Windows.  The stack
trace hasn't changed much since this bug was logged, just a few new line #s:

Incident ID 21915614
DocumentViewerImpl::MakeWindow
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 1265]
DocumentViewerImpl::Init
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 545]
nsDocShell::SetupNewViewer
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2931]
nsWebShell::SetupNewViewer
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 359]
nsDocShell::Embed [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp,
line 2505]
nsWebShell::Embed [d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp,
line 383]
nsDocShell::CreateContentViewer
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2697]
nsDSURIContentListener::DoContent
[d:\builds\seamonkey\mozilla\docshell\base\nsDSURIContentListener.cpp, line 104]
nsDocumentOpenInfo::DispatchContent
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 370]
nsDocumentOpenInfo::OnStartRequest
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 242]
nsHTTPFinalListener::OnStartRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cpp,
line 1119]
InterceptStreamListener::OnStartRequest
[d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCachedNetData.cpp, line 1186]
nsHTTPServerListener::FinishedResponseHeaders
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cpp,
line 1057]
nsHTTPServerListener::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cpp,
line 428]
nsOnDataAvailableEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 406]
nsStreamListenerEvent::HandlePLEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 106]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 581]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 517]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1051]
KERNEL32.DLL + 0x24407 (0xbff94407)
0x00658b52

John, are the original steps to reproduce still causing this crash?  I have a
lot of comments from talkback reports that might help find new steps.

Comment 13

[Stephen P. Morse]

Reassigning to layout people.

Comment 14

[John Morrison]

The original steps to reproduce no longer work. When I get to step 4) "(2nd 
time) Tasks -> Privacy and Security -> Understanding Privacy", nothing happens:
there is no error, no crash, and no second load of that page. 

(Note: step 3) "Bookmarks -> How to Customize Bookmarks..." was referring to a 
specific bookmarked URL that was part of RTM, but just use any bookmarked URL).

jpatel -- if you can divine some other steps to reproduce this crash, that 
would be good. [I never expected this was unique to that one set of steps].
  

Comment 15

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

Please triage.

Comment 16

[verah (gone)]

Copying Steve Rudman and removing myself from list of cc's.

Comment 17

[Chris Petersen]

John,
Is this problem still occuring ? I tried on the 20010111608 Mac build but can't
reproduce the crash as described.

Comment 18

[John Morrison]

No, these steps no longer reproduce the crash for me (see my comment 11/29). 
Actually, you don't crash now, because you can't do step 4 -- the browser
simply takes no action of any kind, positive or negative.

I also checked the recent crash data, and this signature is no longer appearing 
on the list of common crashes for the trunk builds.

Comment 19

[Nisheeth Ranjan]

Removing topcrash keyword based on John Morrison's comment timestamped 
"2001-01-16 16:36".

Comment 20

[Johnny Stenback (:jst)]

Is someone still able to reproduce this or could this be closed?

Comment 21

[John Morrison]

I can't. Resolving as Worksforme (but if someone can force this crash, then 
reopen).

Comment 22

[Jay Patel [:jay]]

changing summary to N601 for tracking...since this is still a topcrasher with
the N601 build.

Comment 23

[Jay Patel [:jay]]

adding topcrash keyword for tracking.

Comment 24

[Chris Petersen]

John,

I'm not able to crash based on the steps given. Is this still happening for you ?

Comment 25

[John Morrison]

Nope. vrfy wfm (although I accidentally marked fixed earlier, but really it's 
wfm).