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

VERIFIED FIXED in Future

Status

()

P3
critical
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: jrgmorrison, Assigned: jst)

Tracking

({crash, topcrash})

Trunk
Future
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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)
(Reporter)

Comment 1

18 years ago
Oops. -> morse
Assignee: clayton → morse
Keywords: crash

Comment 2

18 years ago
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

18 years ago
Are there any reproducible steps for those of us that don't have the commercial 
help you mentioned?
(Reporter)

Comment 4

18 years ago
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

18 years ago
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
Severity: normal → critical

Comment 6

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

Comment 7

18 years ago
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

18 years ago
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

18 years ago
Created attachment 18588 [details]
help_security.xul

Comment 10

18 years ago
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

18 years ago
Created attachment 18589 [details]
help_security.xul as a text file.

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → M20

Updated

18 years ago
Summary: crash in DocumentViewerImpl::MakeWindow; triggered from xul for 'understanding privacy' → [x]crash in DocumentViewerImpl::MakeWindow; triggered from xul for 'understanding privacy'
Target Milestone: M20 → ---

Updated

18 years ago
Summary: [x]crash in DocumentViewerImpl::MakeWindow; triggered from xul for 'understanding privacy' → crash in DocumentViewerImpl::MakeWindow; triggered from xul for 'understanding privacy'
Whiteboard: [x]

Comment 12

18 years ago
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.
Keywords: topcrash
Summary: crash in DocumentViewerImpl::MakeWindow; triggered from xul for 'understanding privacy' → crash in [@ DocumentViewerImpl::MakeWindow]; triggered from xul for 'understanding privacy'

Comment 13

18 years ago
Reassigning to layout people.
Assignee: morse → clayton
Status: ASSIGNED → NEW
(Reporter)

Comment 14

18 years ago
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].
  

Updated

18 years ago
Summary: crash in [@ DocumentViewerImpl::MakeWindow]; triggered from xul for 'understanding privacy' → RTM crash #7 [@ DocumentViewerImpl::MakeWindow]; triggered from xul for 'understanding privacy'
Please triage.
Assignee: clayton → jst

Comment 16

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

Updated

18 years ago
Whiteboard: [x]

Comment 17

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

Comment 18

18 years ago
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

18 years ago
Removing topcrash keyword based on John Morrison's comment timestamped 
"2001-01-16 16:36".
Keywords: topcrash
Target Milestone: --- → Future
(Assignee)

Comment 20

18 years ago
Is someone still able to reproduce this or could this be closed?
(Reporter)

Comment 21

18 years ago
I can't. Resolving as Worksforme (but if someone can force this crash, then 
reopen).
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 22

18 years ago
changing summary to N601 for tracking...since this is still a topcrasher with
the N601 build.
Summary: RTM crash #7 [@ DocumentViewerImpl::MakeWindow]; triggered from xul for 'understanding privacy' → N601 crash #7 [@ DocumentViewerImpl::MakeWindow]; triggered from xul for 'understanding privacy'

Comment 23

18 years ago
adding topcrash keyword for tracking.
Keywords: topcrash

Comment 24

18 years ago
John,

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

Comment 25

18 years ago
Nope. vrfy wfm (although I accidentally marked fixed earlier, but really it's 
wfm).
Status: RESOLVED → VERIFIED
Crash Signature: [@ DocumentViewerImpl::MakeWindow]
You need to log in before you can comment on or make changes to this bug.