46426 - crash deleting and selecting local messages quickly

Status: VERIFIED DUPLICATE of bug 42109

(Core :: XUL, defect, P3)

Description

[David :Bienvenu]

I crashed with the following stack. If I advance the IP in the debugger, I can
continue past the crash no problem, so a simple check for null would fix this.
Assigning to Hyatt since it seems tree control-related.

nsXULTreeElement::SelectItemRange(nsXULTreeElement * const 0x03432448,
nsIDOMXULElement * 0x00000000, nsIDOMXULElement * 0x065561dc) line 311 + 53 bytes
XULTreeElementSelectItemRange(JSContext * 0x023c4b50, JSObject * 0x02de20e0,
unsigned int 0x00000002, long * 0x056341dc, long * 0x0012db58) line 463 + 33 bytes
js_Invoke(JSContext * 0x023c4b50, unsigned int 0x00000002, unsigned int
0x00000000) line 716 + 23 bytes
js_Interpret(JSContext * 0x023c4b50, long * 0x0012e494) line 2517 + 15 bytes
js_Invoke(JSContext * 0x023c4b50, unsigned int 0x00000001, unsigned int
0x00000002) line 732 + 13 bytes
js_InternalInvoke(JSContext * 0x023c4b50, JSObject * 0x0532e6d0, long
0x055da4d8, unsigned int 0x00000000, unsigned int 0x00000001, long * 0x0012e628,
long * 0x0012e5b8) line 805 + 19 bytes
JS_CallFunctionValue(JSContext * 0x023c4b50, JSObject * 0x0532e6d0, long
0x055da4d8, unsigned int 0x00000001, long * 0x0012e628, long * 0x0012e5b8) line
2817 + 31 bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x023c4ce0, void * 0x0532e6d0,
void * 0x055da4d8, unsigned int 0x00000001, void * 0x0012e628, int * 0x0012e624,
int 0x00000000) line 847 + 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x04736254) line 154 + 64 bytes
nsXBLEventHandler::ExecuteHandler(nsXBLEventHandler * const 0x064f8960, const
nsString & {...}, nsIDOMEvent * 0x04736254) line 629
nsXBLEventHandler::MouseClick(nsIDOMEvent * 0x04736254) line 177 + 44 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x023c50d0, nsEvent *
0x0012f418, nsIDOMEvent * * 0x0012f390, nsIDOMEventTarget * 0x064f8040, unsigned
int 0x00000002, nsEventStatus * 0x0012f79c) line 845 + 23 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x064f8030, nsIPresContext *
0x023c50d0, nsEvent * 0x0012f418, nsIDOMEvent * * 0x0012f390, unsigned int
0x00000002, nsEventStatus * 0x0012f79c) line 3350


currentItem is null, so we crash.

  while (PR_TRUE) {
      content = do_QueryInterface(currentItem);
      content->GetTag(*getter_AddRefs(tag));
      if (tag && tag.get() == kTreeItemAtom)
          content->SetAttribute(kNameSpaceID_None, kSelectedAtom,
          trueString, /*aNotify*/ PR_TRUE);
      if (currentItem == aEndItem)
          break;
      nsCOMPtr<nsIDOMElement> nextItem;
      treebox->GetNextItem(currentItem, 1, getter_AddRefs(nextItem));
      currentItem = nextItem;
  }

Comment 1

[Peter Trudelle]

->bryner as nsbeta3+.  Need steps to reproduce in bug report.

Comment 2

[Brian Ryner (not reading)]

What build did you see this on?  Can you retest with a build from 7/27 or newer?
(hyatt checked in some massive tree changes the evening of 7/26)

Thanks.

Comment 3

[Brian Ryner (not reading)]

I need some steps to reproduce this...

Comment 4

[Eli Goldberg]

If this is related to a widget, it's not really selection (which is for text 
selection).

Handing off to jrgm.

Comment 5

[David :Bienvenu]

I'll try again with a recent build. The way I reproduced it was to select
messages (both singly and multiply) and delete quickly - I would change the
selection while the previous delete was going on. I don't have reproducible
steps because it involved a lot of destructive behaviour. However, the fix was
trivial, as I said.

Comment 6

[David :Bienvenu]

I was not able to reproduce this. However, bulletproofing the code wouldn't hurt!

Comment 7

[Brian Ryner (not reading)]

Actually, I have another bug dealing with needing to update the current item
correctly on deletion (#42109).  Mind if I mark this a dup?

Comment 8

[David :Bienvenu]

sure, go for it.

Comment 9

[Brian Ryner (not reading)]

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

Comment 10

[lchiang]

verified dup.  I've marked the other one "mailtrack" so we can track in mail.

Comment 11

[John Morrison]

Really marking verified this time.