121548 - ASSERTION: QueryInterface needed: 'query_result.get() == mRawPtr'

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[timeless]

###!!! ASSERTION: QueryInterface needed: 'query_result.get() == mRawPtr', file 
../../../dist\include\\xpcom\nsCOMPtr.h, line 501
###!!! Break: at file ../../../dist\include\\xpcom\nsCOMPtr.h, line 501

nsDebug::Assertion(const char * 0x020c6dcc `string', const char * 0x020c6de8 
`string', const char * 0x020ce72c `string', int 501) line 290 + 13 bytes
nsCOMPtr<nsIDOMNode>::Assert_NoQueryNeeded() line 501 + 41 bytes
nsCOMPtr<nsIDOMNode>::nsCOMPtr<nsIDOMNode>(nsIDOMNode * 0x0751cba0) line 537
nsXULElement::IsAncestor(nsIDOMNode * 0x0731a934, nsIDOMNode * 0x0751cba0) line 
4342
nsXULElement::RemoveChildAt(nsXULElement * const 0x073197e0, int 0, int 1) line 
2391 + 23 bytes
nsXULContentBuilder::RemoveMember(nsIContent * 0x06bf7e90, nsIRDFResource * 
0x053af120, int 1) line 1141 + 40 bytes
nsXULContentBuilder::ReplaceMatch(nsIRDFResource * 0x053af120, const 
nsTemplateMatch * 0x07318d10, nsTemplateMatch * 0x00000000) line 1872
nsXULTemplateBuilder::Retract(nsIRDFResource * 0x04391aa0, nsIRDFResource * 
0x04391a20, nsIRDFNode * 0x053af120) line 610
nsXULTemplateBuilder::OnUnassert(nsXULTemplateBuilder * const 0x06bf749c, 
nsIRDFDataSource * 0x06bf8ac0, nsIRDFResource * 0x04391aa0, nsIRDFResource * 
0x04391a20, nsIRDFNode * 0x053af120) line 646
CompositeDataSourceImpl::OnUnassert(CompositeDataSourceImpl * const 0x06bf8ac4, 
nsIRDFDataSource * 0x04ea8210, nsIRDFResource * 0x04391aa0, nsIRDFResource * 
0x04391a20, nsIRDFNode * 0x053af120) line 1589
nsMsgRDFDataSource::unassertEnumFunc(nsISupports * 0x06bf8ac4, void * 
0x0012aad8) line 415
nsSupportsArray::EnumerateForwards(nsSupportsArray * const 0x04ea81a0, int 
(nsISupports *, void *)* 0x0487c3a0 
nsMsgRDFDataSource::unassertEnumFunc(nsISupports *, void *), void * 0x0012aad8) 
line 684 + 20 bytes
nsMsgRDFDataSource::NotifyObservers(nsIRDFResource * 0x04391aa0, nsIRDFResource 
* 0x04391a20, nsIRDFNode * 0x053af120, int 0, int 0) line 389
nsMsgAccountManagerDataSource::OnServerUnloaded(nsMsgAccountManagerDataSource * 
const 0x04ea8244, nsIMsgIncomingServer * 0x053853f0) line 1163
nsMsgAccountManager::NotifyServerUnloaded(nsMsgAccountManager * const 
0x0438ecc0, nsIMsgIncomingServer * 0x053853f0) line 1667
nsMsgAccountManager::RemoveAccount(nsMsgAccountManager * const 0x0438ecc0, 
nsIMsgAccount * 0x05385840) line 656
XPTC_InvokeByIndex(nsISupports * 0x0438ecc0, unsigned int 5, unsigned int 1, 
nsXPTCVariant * 0x0012adec) line 106
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode 
CALL_METHOD) line 1998 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x05dd77e0, JSObject * 0x06095da8, unsigned int 
1, long * 0x060990c0, long * 0x0012b094) line 1266 + 14 bytes
js_Invoke(JSContext * 0x05dd77e0, unsigned int 1, unsigned int 0) line 832 + 23 
bytes
js_Interpret(JSContext * 0x05dd77e0, long * 0x0012b95c) line 2798 + 15 bytes
js_Invoke(JSContext * 0x05dd77e0, unsigned int 1, unsigned int 2) line 849 + 13 
bytes
js_InternalInvoke(JSContext * 0x05dd77e0, JSObject * 0x05f8d6b8, long 50171304, 
unsigned int 0, unsigned int 1, long * 0x0012bbcc, long * 0x0012ba84) line 924 
+ 20 bytes
JS_CallFunctionValue(JSContext * 0x05dd77e0, JSObject * 0x05f8d6b8, long 
50171304, unsigned int 1, long * 0x0012bbcc, long * 0x0012ba84) line 3405 + 31 
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x05dd7990, void * 
0x05f8d6b8, void * 0x02fd8da8, unsigned int 1, void * 0x0012bbcc, int * 
0x0012bbd0, int 0) line 1011 + 33 bytes
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x06bf8230, 
nsIDOMEvent * 0x05288a98) line 180 + 77 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x06bf8190, 
nsIDOMEvent * 0x05288a98, nsIDOMEventTarget * 0x06bf82e8, unsigned int 8, 
unsigned int 7) line 1205 + 20 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x06bf8280, 
nsIPresContext * 0x05298940, nsEvent * 0x0012c6fc, nsIDOMEvent * * 0x0012c5ac, 
nsIDOMEventTarget * 0x06bf82e8, unsigned int 7, nsEventStatus * 0x0012c744) 
line 2195 + 36 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x06bf82e0, nsIPresContext * 
0x05298940, nsEvent * 0x0012c6fc, nsIDOMEvent * * 0x0012c5ac, unsigned int 1, 
nsEventStatus * 0x0012c744) line 3359
PresShell::HandleDOMEventWithTarget(PresShell * const 0x059ba990, nsIContent * 
0x06bf82e0, nsEvent * 0x0012c6fc, nsEventStatus * 0x0012c744) line 6033 + 36 
bytes
nsButtonBoxFrame::MouseClicked(nsIPresContext * 0x05298940, nsGUIEvent * 
0x0012c8ec) line 195
nsButtonBoxFrame::HandleEvent(nsButtonBoxFrame * const 0x0609db5c, 
nsIPresContext * 0x05298940, nsGUIEvent * 0x0012c8ec, nsEventStatus * 
0x0012cbe8) line 142
PresShell::HandleEventInternal(nsEvent * 0x0012c8ec, nsIView * 0x00000000, 
unsigned int 1, nsEventStatus * 0x0012cbe8) line 6001 + 38 bytes
PresShell::HandleEventWithTarget(PresShell * const 0x059ba990, nsEvent * 
0x0012c8ec, nsIFrame * 0x0609db5c, nsIContent * 0x06bf82e0, unsigned int 1, 
nsEventStatus * 0x0012cbe8) line 5955 + 22 bytes
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 
0x06c19910, nsIPresContext * 0x05298940, nsMouseEvent * 0x0012ccec, 
nsEventStatus * 0x0012cbe8) line 2462 + 63 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x06c19918, 
nsIPresContext * 0x05298940, nsEvent * 0x0012ccec, nsIFrame * 0x0609db5c, 
nsEventStatus * 0x0012cbe8, nsIView * 0x052ab2b0) line 1544 + 28 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012ccec, nsIView * 0x052ab2b0, 
unsigned int 1, nsEventStatus * 0x0012cbe8) line 6006 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x059ba994, nsIView * 0x052ab2b0, 
nsGUIEvent * 0x0012ccec, nsEventStatus * 0x0012cbe8, int 1, int & 1) line 5909 
+ 25 bytes
nsView::HandleEvent(nsView * const 0x052ab2b0, nsGUIEvent * 0x0012ccec, 
unsigned int 0, nsEventStatus * 0x0012cbe8, int 1, int & 1) line 387
nsViewManager::DispatchEvent(nsViewManager * const 0x052e1ea0, nsGUIEvent * 
0x0012ccec, nsEventStatus * 0x0012cbe8) line 1909
HandleEvent(nsGUIEvent * 0x0012ccec) line 83
nsWindow::DispatchEvent(nsWindow * const 0x053fba24, nsGUIEvent * 0x0012ccec, 
nsEventStatus & nsEventStatus_eIgnore) line 850 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012ccec) line 871
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 4527 
+ 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 
4779
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 23199834, long 
* 0x0012d0dc) line 3419 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x008e13fc, unsigned int 514, unsigned int 0, 
long 23199834) line 1115 + 27 bytes
USER32! 77e12e98()
USER32! 77e130e0()
USER32! 77e15824()
nsXULWindow::ShowModal(nsXULWindow * const 0x05dd6190) line 283
nsWebShellWindow::ShowModal(nsWebShellWindow * const 0x05dd6190) line 1102
nsContentTreeOwner::ShowAsModal(nsContentTreeOwner * const 0x05debc5c) line 434
nsWindowWatcher::OpenWindowJS(nsWindowWatcher * const 0x004b49f4, nsIDOMWindow 
* 0x03d9e114, const char * 0x05dd7440, const char * 0x05dd3070, const char * 
0x05dd73f0, int 1, unsigned int 1, long * 0x05ffb96c, nsIDOMWindow * * 
0x0012d7e4) line 699
GlobalWindowImpl::OpenInternal(GlobalWindowImpl * const 0x03d9e110, const 
nsAString & {...}, const nsAString & {...}, const nsAString & {...}, int 1, 
long * 0x05ffb960, unsigned int 4, nsISupports * 0x00000000, nsIDOMWindow * * 
0x0012dba0) line 3522 + 129 bytes
GlobalWindowImpl::OpenDialog(GlobalWindowImpl * const 0x03d9e118, nsIDOMWindow 
* * 0x0012dba0) line 2530 + 59 bytes
XPTC_InvokeByIndex(nsISupports * 0x03d9e118, unsigned int 14, unsigned int 1, 
nsXPTCVariant * 0x0012dba0) line 106
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode 
CALL_METHOD) line 1998 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x03d9f760, JSObject * 0x02f278a0, unsigned int 
4, long * 0x05ffb960, long * 0x0012de48) line 1266 + 14 bytes
js_Invoke(JSContext * 0x03d9f760, unsigned int 4, unsigned int 0) line 832 + 23 
bytes
js_Interpret(JSContext * 0x03d9f760, long * 0x0012e710) line 2798 + 15 bytes
js_Invoke(JSContext * 0x03d9f760, unsigned int 1, unsigned int 2) line 849 + 13 
bytes
js_InternalInvoke(JSContext * 0x03d9f760, JSObject * 0x02fd9158, long 50174864, 
unsigned int 0, unsigned int 1, long * 0x0012e980, long * 0x0012e838) line 924 
+ 20 bytes
JS_CallFunctionValue(JSContext * 0x03d9f760, JSObject * 0x02fd9158, long 
50174864, unsigned int 1, long * 0x0012e980, long * 0x0012e838) line 3405 + 31 
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x03d9fa20, void * 
0x02fd9158, void * 0x02fd9b90, unsigned int 1, void * 0x0012e980, int * 
0x0012e984, int 0) line 1011 + 33 bytes
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x04e99880, 
nsIDOMEvent * 0x05dcde28) line 180 + 77 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x04e99670, 
nsIDOMEvent * 0x05dcde28, nsIDOMEventTarget * 0x04dbc648, unsigned int 8, 
unsigned int 7) line 1205 + 20 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x04e998d0, 
nsIPresContext * 0x04318080, nsEvent * 0x0012f4b4, nsIDOMEvent * * 0x0012f360, 
nsIDOMEventTarget * 0x04dbc648, unsigned int 7, nsEventStatus * 0x0012f500) 
line 2195 + 36 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x04dbc640, nsIPresContext * 
0x04318080, nsEvent * 0x0012f4b4, nsIDOMEvent * * 0x0012f360, unsigned int 1, 
nsEventStatus * 0x0012f500) line 3359
PresShell::HandleDOMEventWithTarget(PresShell * const 0x0431ad50, nsIContent * 
0x04dbc640, nsEvent * 0x0012f4b4, nsEventStatus * 0x0012f500) line 6033 + 36 
bytes
nsMenuFrame::Execute() line 1634
nsMenuFrame::HandleEvent(nsMenuFrame * const 0x05ffa9b0, nsIPresContext * 
0x04318080, nsGUIEvent * 0x0012f930, nsEventStatus * 0x0012f82c) line 487
PresShell::HandleEventInternal(nsEvent * 0x0012f930, nsIView * 0x05d5dbb0, 
unsigned int 1, nsEventStatus * 0x0012f82c) line 6001 + 38 bytes
PresShell::HandleEvent(PresShell * const 0x0431ad54, nsIView * 0x05d5dbb0, 
nsGUIEvent * 0x0012f930, nsEventStatus * 0x0012f82c, int 0, int & 1) line 5909 
+ 25 bytes
nsView::HandleEvent(nsView * const 0x05d5dbb0, nsGUIEvent * 0x0012f930, 
unsigned int 0, nsEventStatus * 0x0012f82c, int 0, int & 1) line 387
nsView::HandleEvent(nsView * const 0x05d24bc0, nsGUIEvent * 0x0012f930, 
unsigned int 0, nsEventStatus * 0x0012f82c, int 0, int & 1) line 344
nsView::HandleEvent(nsView * const 0x059b53c0, nsGUIEvent * 0x0012f930, 
unsigned int 0, nsEventStatus * 0x0012f82c, int 0, int & 1) line 344
nsView::HandleEvent(nsView * const 0x04319570, nsGUIEvent * 0x0012f930, 
unsigned int 0, nsEventStatus * 0x0012f82c, int 1, int & 1) line 344
nsViewManager::DispatchEvent(nsViewManager * const 0x04319710, nsGUIEvent * 
0x0012f930, nsEventStatus * 0x0012f82c) line 1909
HandleEvent(nsGUIEvent * 0x0012f930) line 83
nsWindow::DispatchEvent(nsWindow * const 0x05d20ef4, nsGUIEvent * 0x0012f930, 
nsEventStatus & nsEventStatus_eIgnore) line 850 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f930) line 871
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 4527 
+ 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 
4779
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 14680119, long 
* 0x0012fd20) line 3419 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x008b136c, unsigned int 514, unsigned int 0, 
long 14680119) line 1115 + 27 bytes
USER32! 77e12e98()
USER32! 77e130e0()
USER32! 77e15824()
nsAppShellService::Run(nsAppShellService * const 0x004b3270) line 303
main1(int 3, char * * 0x00444340, nsISupports * 0x00000000) line 1285 + 32 
bytes
main(int 3, char * * 0x00444340) line 1625 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e97d08()

PRBool
nsXULElement::IsAncestor(nsIDOMNode* aParentNode, nsIDOMNode* aChildNode)
{
  nsCOMPtr<nsIDOMNode> parent = dont_QueryInterface(aChildNode);
  while (parent && (parent != aParentNode)) {
    nsCOMPtr<nsIDOMNode> newParent;
    parent->GetParentNode(getter_AddRefs(newParent));
    parent = newParent;
  }

-	aChildNode	0x0751cba0
-	[nsXPCWrappedJS]	{...}
+	nsXPTCStubBase	{...}
+	nsIXPConnectWrappedJS	{...}
+	nsSupportsWeakReference	{...}
+	nsIPropertyBag	{...}
	mRefCnt	4
	_mOwningThread	0x00442460
+	mJSObj	0x06096418
+	mClass	0x0751cea0
+	mRoot	0x0751cba0
+	mNext	0x00000000
+	mOuter	0x0731a930
-	nsISupports	{...}
+	__vfptr	0x0114054c const  nsXPCWrappedJS::`vftable'{for 
`nsXPTCStubBase'}
+	aParentNode	0x0731a934
+	parent	{...}

              NS_ASSERTION(query_result.get() == mRawPtr, "QueryInterface 
needed");
-	query_result	{...}
+	mRawPtr	0x0731a934
-	this	0x0012a538
+	mRawPtr	0x0751cba0

I'm pretty sure i triggered this by removing an imap account using the mail 
accounts dialog (the imap account was known to mozilla as inaccessible).

Unfortunatley in trying to reproduce this i tripped on some more asserts and 
stuff, so i'm going to file a chain of bugs and try to sort this out after i 
get those out of the way.

The first thing i ran into is:
WARNING: XBL load did not complete until after document went away! Modal dialog 
bug?
, file f:\build\mozilla\content\xbl\src\nsXBLService.cpp, line 358

I got it 14 times (which probably relates to the number of rows in the 
tree/outliner i was walking through).

then i got:
Error reading file 
jar:resource:///chrome/messenger.jar!/content/messenger/addressbook/pref-direct
ory.js
Failed to load 
jar:resource:///chrome/messenger.jar!/content/messenger/addressbook/pref-direct
ory.js
###!!! ASSERTION: no script global object: 'mScriptGlobalObject != nsnull', 
file f:\build\mozilla\content\xul\document\src\nsXULDocument.cpp, line 6196
###!!! Break: at file 
f:\build\mozilla\content\xul\document\src\nsXULDocument.cpp, line 6196

I suspect these two (load failure+assert) are a pair.

Comment 1

[Joe Hewitt (gone)]

This assertion is due to an issue with XPConnect.  A wrapped js object is being
passed into RemoveChildAt, and QI is having issues with it. 

Comment 2

[John Bandhauer]

hewitt: Do you know what issue exactly? If there is code that assumes that a
given pointer has already been QI'd to a given interface and it has not been,
then maybe that code needs to do some QI'ing?

Still, I can imagine one place where we *might* run into a problem where
xpconnect might cough up a different pointer for a wrapped JSObject when asking
for a given iid depending on whether the caller QI'd the wrapper vs. implicit
wrapper creation. This could happen if there are multiple interfaces on the
object and an inheritence relationship exists between the interfaces. There is
code in nsXPCWrappedJS::GetNewOrUsed that will add to a wrapper's wrapper chain
if no wrapper exists for a given iid. But, the code in
nsXPCWrappedJSClass::DelegatedQueryInterface allows for the posibility that
there may be a wrapper already for an interface that inherits from the one the
caller is asking for. In that case it will return that existing wrapper.

Even if that is not the problem here, dbradley ought to add that to his list of
bugs. I think the fix is going to be to add a FindInherited() section after the
(failure of the) root->Find(aIID) call in nsXPCWrappedJS::GetNewOrUsed. That
would require a test case and some testing, but I think that ought to matter.
I'm having trouble coming up with a thought experiment where this would actually
cause a problem like this, but I still think it might.

Please reassign to the xpconnect module owner (dbradley) unless you know of some
better plan of attack.

Comment 3

[timeless]

reassign to dbradley per jband

Comment 4

[David Bradley]

I think I understand. There's a wrapper in the chain with this interface but
we're creating a new one because we don't walk the chain when we look for the
interface.

I don't think that could be the problem in this case. If I read the data at the
end of the stack trace correctly. This wrapped JS is not part of a chain.
aChildNode == mRoot and mNext is null. But then I'm not at all sure I'm reading
that data right.

timeless: when possible try and put such long stacks in a file and attach that.

Comment 5

[John Bandhauer]

dbradley: We *do* walk the chain. The disparity is that in the QI case we walk
the chain twice: once to look for exact matches and then again to look for
interfaces that inherit from the requested interface. In the QI case we only
walk the chain once - so miss the inheritence relationship and build a new
wrapper. I'm not at all certain that this is the cause of this problem, but I
believe that it *is* wrong and that we ought to walk the chain twice in the
GetNewOrUsed case also. I think we do want to continue the practice of walking
the chain twice because we want to not miss an exact match if it exists before
we accept an inheritence match.

Comment 6

[David Bradley]

I agree that it needs to be fixed, I just wanted to make sure I had a full
understanding of the problem before I went and filed the bug.

Comment 7

[David Bradley]

Bug 121938 now deals specifically with the FindInheritance issue.

Comment 8

[David Bradley]

timeless if you can try the patch
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=66543 in bug 121938 and
let me know if this fixes the problem, that would be great. I don't think it
will, but maybe we'll get lucky. Hoping I'm read the data you posted wrong.

Comment 9

[jag (Peter Annema)]

How does this differ from bug 127315?

Comment 10

[timeless]

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

Comment 11

[timeless]

re comment 8: it doesn't help. see comment 9 :-(

Comment 12

[jag (Peter Annema)]

PRBool
nsXULElement::IsAncestor(nsIDOMNode* aParentNode, nsIDOMNode* aChildNode)
{
  nsCOMPtr<nsIDOMNode> parent = dont_QueryInterface(aChildNode);

|aChildNode| is already a nsIDOMNode* and shouldn't need a QI to be assigned 
into the nsCOMPtr. I completely agree with jband, no bandaids.

It does look like the nsXPCWrappedJS object hands out a different pointer when 
QI'd to nsIDOMNode, than when QI'd to nsIDOMXULSelectControlItemElement. Since 
nsIDOMXULSelectControlItemElement (indirectly) inherits from nsIDOMNode, that 
shouldn't be the case (I think).

I added the following code right before the IsAncestor call:

  //XXXjag
  nsCOMPtr<nsIDOMXULSelectControlItemElement> a(do_QueryInterface(node));
  nsCOMPtr<nsIDOMNode> b(do_QueryInterface(node));

The first goes through:

nsXULElement::RemoveChildAt
nsCOMPtr<nsIDOMXULSelectControlItemElement>::nsCOMPtr<nsIDOMXULSelectControlItem
Element>
nsCOMPtr<nsIDOMXULSelectControlItemElement>::assign_from_helper
nsQueryInterface::operator()
nsXPCWrappedJS::QueryInterface
nsXULElement::QueryInterface
nsBindingManager::GetBindingImplementation
nsXPCWrappedJS::AggregatedQueryInterface
nsXPCWrappedJSClass::DelegatedQueryInterface:

    if(nsnull != (sibling = self->Find(aIID)))
    {
        NS_ADDREF(sibling);
=>      *aInstancePtr = (void*) sibling;
        return NS_OK;
    }

The second goes through:

nsXULElement::RemoveChildAt
nsCOMPtr<nsIDOMNode>::nsCOMPtr<nsIDOMNode>
nsCOMPtr<nsIDOMNode>::assign_from_helper
nsQueryInterface::operator()
nsXPCWrappedJS::QueryInterface
nsXULElement::QueryInterface:

    else if (iid.Equals(NS_GET_IID(nsIDOMXULElement)) ||
             iid.Equals(NS_GET_IID(nsIDOMElement)) ||
             iid.Equals(NS_GET_IID(nsIDOMNode))) {
=>      *result = NS_STATIC_CAST(nsIDOMXULElement*, this);
    }

Hope that helps.

Oh, my test case is to reply-all to an e-mail with multiple recipients, then 
remove the first To: field (select and delete the text, then press delete or 
backspace to remove the field completely).

Comment 13

[John Bandhauer]

jag: thanks for injecting more data. The stacks you show do not necessarily show
xpconnect (or the nsXULElement/XBL stuff) doing the wrong thing. Recall that a
given object may implement a given interface through various pointers to the
object. I mean the if an object does multiple inheritance of interfaces that are
not themselves directly related then there may be more than one pointer to the
object that 'correctly' exposes a given base interface. This is espectially
obvious when you consider nsISupports; you can QI a complex object to different
interfaces and receive different pointer values, but each is a pointer to *a*
nsISupports. But only when you explicitly QI asking for nsISupports are you
assured to get *the* nsISupports pointer for the object. (If that made sense
then...) I think we likely have the same thing here. The fact that a given
pointer value for the object is *a* nsIDOMNode pointer does not mean that it is
*the* nsIDOMNode pointer. And the assert in the nsCOMPtr stuff is checking that
you have *the* nsIDOMNode pointer.

XPConnect *tries* to do something as close as possible to what native objects
would do in their QI implmentations. It looks for an exact iid match between the
requested iid and the interface types it knows the object has been declared to
explicitly support (either by having a QI impl, having been explicitly wrapped
by a native caller, or having been used from JS as a param of a particular
type). If no explicit match for the requested iid is found then (in order to be
'nice') xpconnect will fallback to looking for a match with the ancestor types
of the interfaces the object is known to implement (aka FindInherited). This is
something that native QI implmentation may or may not do. It is arguably
unnecessary.

One thing that xpconnect does that is a bit loose with the COM identity rules is
that it can fail in a QI call at one point in time and then later (*after*
support for a given interface has been discovered on the object) a subsequent QI
for the same iid can succeed. I can't see that this is 'fixable'. It is a fact
of mapping  dynamic objects as XPCOM objects and not *requiring* that the
dynamic impelment QI *or* be limited to being allowed to claim support of only
those interfaces discoverable via that QI implmentation. In places where this
might turn out to be a problem, it can be remedied by adding an explicit QI
function to the JS object so that the desired QI behavior will work throughout
the lifetime of the object. This can also help with a related problem: because
of the 'FindInherited' behavior the first QI in this example might not fail, but
will return a different pointer than a subsequent QI on the object.

Nevertheless, it is looking like these issues may or may not have any bearing on
this bug. It *might* be an issue of variance in which interface xpconnect
returns when QI'd for a given iid at one point in time as compared to another
point in time. But, it also might be an issue of assuming that any nsIFoo
pointer to an object will be the same as the nsIFoo pointer received when
explicitly doing a QI and asking for nsIFoo. This problem is independent of the
implmentation language of the object in question. It is inherent to COM. And is
only a problem if the usage patterns of the caller do not take this fact into
account.

So, answering the question of what is going wrong here will still require
looking closer at the using code in question.

Comment 14

[David Bradley]

Is this still an issue? I'm not seeing the assertion anymore in IsAncestor,
using Jag's test case. That's only because curNode is always null. I can't get
to the path timeless posted by removing an imap account, either. So I'm not sure
if the problem has been solved, or just covered up.

Comment 15

[timeless]

i lost almost all of my fun machines ... i'm currently very behind in mail, 
projects, job hunting and cvs builds.

Comment 16

[David Bradley]

Need some followup on this. Suspecting we can mark this fixed.

Comment 17

[David Bradley]

Moving out

Comment 18

[David Bradley]

Marking this fixed, if anyone sees this problem, please reopen.

Comment 19

[Phil Schwartau]

Rubber-stamp vrfy -