52970 - UI Crash in Cookie Manager, Password Manager, Form Manager

Status: VERIFIED DUPLICATE of bug 53116

(SeaMonkey :: Themes, defect, P3)

Description

[Erich 'Ricky' Iseli]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20000915
BuildID:    2000091505

Mozilla crashes if I attempt to select the following Menu Item:
Tasks|Privacy and Security|Cookie Manager|View Stored Cookies
I haven't tried other Menu Items, but it looks like the Cookies Security doesn't
work at all, since when browsing with this build, I don't get any warnings like
"this site wants to set a cookie"

Reproducible: Always
Steps to Reproduce:
1. Select "View Stored Cookies" via the Tasks menu

Actual Results:  Crash			

Expected Results:  View stored cookies

Comment 1

[Erich 'Ricky' Iseli]

This also happens if you go through Edit|Preferences|Advanced|Cookies and press 
button View stored cookies.

Forget my previous note that the warning for cookies did not work. I didn't 
notice that when I installed that build, it did not remember my previous 
preferences.

Comment 2

[Stephen P. Morse]

Yes, I'm seeing this too.  Looks like infinite recursion from the stacktrace 
(note that the beginning of the stacktrace seems to be lost).  And the recursion 
is in layout so I'm reassigning.

NS_CurrentThread() line 463
NS_CheckThreadSafe(void * 0x00ab2eb0, const char * 0x012424f0) line 490 + 5 
bytes
nsXULElement::AddRef(nsXULElement * const 0x033c3bc0) line 517 + 58 bytes
nsXULElement::QueryInterface(nsXULElement * const 0x033c3bc0, const nsID & 
{...}, void * * 0x00033110) line 613
nsQueryInterface::operator()(const nsID & {...}, void * * 0x00033110) line 32 + 
25 bytes
nsCOMPtr<nsIContent>::assign_from_helper(const nsCOMPtr_helper & {...}, const 
nsID & {...}) line 856 + 18 bytes
nsCOMPtr<nsIContent>::nsCOMPtr<nsIContent>(const nsQueryInterface & {...}) line 
565
nsCOMPtr<nsIContent>::Assert_NoQueryNeeded() line 500
nsGetterAddRefs<nsIContent>::~nsGetterAddRefs<nsIContent>() line 909
nsBoxFrame::GetInsertionPoint(nsIPresShell * 0x0336c7b0, nsIFrame * 0x00d58fc4, 
nsIFrame * 0x00e4b74c, nsIFrame * * 0x00033260) line 1853

and nsBoxFrame::GetInsertionPoint line is repeated about 1000 times.  Anything 
preceding that on the stack has been lost so we don't know who originally 
called this routine.

Comment 3

[Stephen P. Morse]

Same crash when going to tasks->privacy->password-manager->view-passwords.

Comment 4

[Stephen P. Morse]

Also tasks->privacy->forms-manager->view-sites.

Comment 5

[Stephen P. Morse]

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

Comment 6

[Stephen P. Morse]

Here's the beginning (bottom) of the stack trace -- i.e., the part preceding the 
1000 occurences of nsBoxFrame::GetInsertionPoint

nsBoxFrame::GetInsertionPoint(nsIPresShell * 0x033cd170, nsIFrame * 0x00e3e09c, 
nsIFrame * 0x00f1e63c, nsIFrame * * 0x0012b0a0) line 1886
nsBoxFrame::GetInsertionPoint(nsIPresShell * 0x033cd170, nsIFrame * 0x00e3e09c, 
nsIFrame * 0x00f1e63c, nsIFrame * * 0x0012b140) line 1886 + 21 bytes
nsBoxFrame::GetInsertionPoint(nsIPresShell * 0x033cd170, nsIFrame * 0x00e3e09c, 
nsIFrame * 0x00f1e63c, nsIFrame * * 0x0012b198) line 1886 + 21 bytes
nsBoxFrame::InsertFrames(nsBoxFrame * const 0x00e3e09c, nsIPresContext * 
0x033cdd10, nsIPresShell & {...}, nsIAtom * 0x00000000, nsIFrame * 0x00e3e378, 
nsIFrame * 0x00f1e63c) line 1078 + 21 bytes
FrameManager::InsertFrames(FrameManager * const 0x033ce8a0, nsIPresContext * 
0x033cdd10, nsIPresShell & {...}, nsIFrame * 0x00e3e09c, nsIAtom * 0x00000000, 
nsIFrame * 0x00e3e378, nsIFrame * 0x00f1e63c) line 718
nsCSSFrameConstructor::ContentInserted(nsCSSFrameConstructor * const 0x033cd4e0, 
nsIPresContext * 0x033cdd10, nsIContent * 0x03424520, nsIContent * 0x03424270, 
int 2, nsILayoutHistoryState * 0x03457760) line 8848 + 71 bytes
nsCSSFrameConstructor::RecreateFramesForContent(nsIPresContext * 0x033cdd10, 
nsIContent * 0x03424270) line 11097 + 40 bytes
nsCSSFrameConstructor::AttributeChanged(nsCSSFrameConstructor * const 
0x033cd4e0, nsIPresContext * 0x033cdd10, nsIContent * 0x03424270, int 0, nsIAtom 
* 0x01aa8a20, int 5) line 9971 + 16 bytes
StyleSetImpl::AttributeChanged(StyleSetImpl * const 0x033cd5a0, nsIPresContext * 
0x033cdd10, nsIContent * 0x03424270, int 0, nsIAtom * 0x01aa8a20, int -1) line 
1195
PresShell::AttributeChanged(PresShell * const 0x033cd178, nsIDocument * 
0x033cbbb0, nsIContent * 0x03424270, int 0, nsIAtom * 0x01aa8a20, int -1) line 
3610 + 57 bytes
nsXULDocument::AttributeChanged(nsXULDocument * const 0x033cbbb0, nsIContent * 
0x03424270, int 0, nsIAtom * 0x01aa8a20, int -1) line 1655
nsXULElement::SetAttribute(nsXULElement * const 0x03424270, nsINodeInfo * 
0x033eeee0, const basic_nsAReadableString<unsigned short> & {...}, int 1) line 
2777
nsXULElement::SetAttribute(nsXULElement * const 0x03424274, const 
basic_nsAReadableString<unsigned short> & {...}, const 
basic_nsAReadableString<unsigned short> & {...}) line 1246 + 31 bytes
ElementSetAttribute(JSContext * 0x033a5c00, JSObject * 0x00d91440, unsigned int 
2, long * 0x00e56f98, long * 0x0012bd10) line 239 + 26 bytes
js_Invoke(JSContext * 0x033a5c00, unsigned int 2, unsigned int 0) line 823 + 23 
bytes
js_Interpret(JSContext * 0x033a5c00, long * 0x0012c844) line 2624 + 15 bytes
js_Invoke(JSContext * 0x033a5c00, unsigned int 1, unsigned int 2) line 840 + 13 
bytes
js_InternalInvoke(JSContext * 0x033a5c00, JSObject * 0x00da0038, long 14289336, 
unsigned int 0, unsigned int 1, long * 0x0012c9dc, long * 0x0012c96c) line 912 + 
20 bytes
JS_CallFunctionValue(JSContext * 0x033a5c00, JSObject * 0x00da0038, long 
14289336, unsigned int 1, long * 0x0012c9dc, long * 0x0012c96c) line 3174 + 31 
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x033a5db0, void * 0x00da0038, 
void * 0x00da09b8, unsigned int 1, void * 0x0012c9dc, int * 0x0012c9d8, int 0) 
line 906 + 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x034ff224) line 154 + 64 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x033ca720, 
nsIDOMEvent * 0x034ff224, nsIDOMEventTarget * 0x033a2660, unsigned int 1, 
unsigned int 7) line 788 + 19 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x033cdd10, nsEvent * 
0x0012cf2c, nsIDOMEvent * * 0x0012cef0, nsIDOMEventTarget * 0x033a2660, unsigned 
int 7, nsEventStatus * 0x0012cf50) line 1365 + 39 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x033a2650, 
nsIPresContext * 0x033cdd10, nsEvent * 0x0012cf2c, nsIDOMEvent * * 0x0012cef0, 
unsigned int 1, nsEventStatus * 0x0012cf50) line 469
DocumentViewerImpl::LoadComplete(DocumentViewerImpl * const 0x033cb340, unsigned 
int 0) line 664 + 47 bytes
nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x033a2dc8, nsIDocumentLoader * 
0x033a2b60, nsIChannel * 0x033c9c80, unsigned int 0) line 981
nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x033a2b60, nsIChannel 
* 0x033c9c80, unsigned int 0) line 805
nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0) line 612
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x033a2b64, nsIChannel * 
0x03473430, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x100a56b0 gCommonEmptyBuffer) line 555
nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x033a2b00, nsIChannel * 
0x03473430, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x100a56b0 gCommonEmptyBuffer) line 566 + 39 bytes
nsJARChannel::OnStopRequest(nsJARChannel * const 0x03473434, nsIChannel * 
0x03470aa0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x100a56b0 gCommonEmptyBuffer) line 934
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x03434d70) line 
302
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03436080) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x03436080) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x033a3d10) line 508 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x003a059e, unsigned int 49437, unsigned int 0, 
long 54148368) line 1044 + 9 bytes
USER32! 77e71268()
033a3d10()

Comment 7

[Stephen P. Morse]

From the above stack dumps, I'm not so sure it's a layout problem after all 
(although the infinite recursion was in layout).  It looks like it might be a 
jar-packing problem.

To verify that I did the following test.  Rather than bringing up the 
CookieViewer from the menu, I tried to bring it up directly from the command 
line.  First I brought up the version that's in the jar file and then brought up 
the version that resides in the chrome directory un-jarred.  The jar version 
crashed whereas the un-jarred version did not.  Here are the URL's that I used:

jar-file (crashed)

   chrome://communicator/content/wallet/CookieViewer.xul

actual file (did not crash)

Y:\mozilla\dist\WIN32_D.OBJ\bin\chrome\packages\core\communicator\content\wallet
\CookieVIewer.xul

Comment 8

[sairuh (rarely reading bugmail)]

since bug 52866 occurs only in the classic skin (at least for me), adding that
kw.

Comment 9

[Stephen P. Morse]

Yes, thanks to Joe Hewitt and Sarah, I checked this using modern skin.  No 
crash.  So now we know what component to assign this to (it's not layout or 
jar-packing after all).  It's themes.  Reassigning once again.

Comment 10

[Stephen P. Morse]

.

Comment 11

[Stephen P. Morse]

Looks like danm already has a fix in hand for bug 53116 which is a dup of this 
one (I just learned about the existence of that other bug).  So I'll mark this 
one as a dup rather than vice versa.

*** This bug has been marked as a duplicate of 53116 ***

Comment 12

[Patty Mac]

Yes, this is a duplicated bug #53116.