456156 - Exception in "messengerdnd.js :: DropOnFolderTree", on canceling folder drop to Trash dialog

Status: NEW

(MailNews Core :: Backend, defect)

Description

[Serge Gautherie (:sgautherie)]

(I noticed this while testing TB bug 456096,
which I mark as blocking as it prevents to know if TB has this one too...)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)

No bug.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080919073847 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

1. Drag and drop a folder to the Trash. (on local folders)
2. Cancel the confirmation dialog.
2r.
{
Error: [Exception... "Component returned failure code: 0x8055001a [nsIMsgCopyService.CopyFolders]"  nsresult: "0x8055001a (<unknown>)"  location: "JS frame :: chrome://messenger/content/messengerdnd.js :: DropOnFolderTree :: line 394"  data: no]
Source File: chrome://messenger/content/messengerdnd.js
Line: 394
}

Without looking, I would guess the code doesn't notice the cancel then tries to move the folder anyway !?

I guess it's a recent regression, but I didn't look into it.

Comment 1

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080927031346 Shredder/3.0b1pre] (nightly) (W2Ksp4)

(Now that bug 456096 is fixed,)
Exact same bug.

Comment 2

[Robert Kaiser]

The wanted flag doesn't apply to real bug, only to features that have higher priority and need special tracking. Real bugs should be nominated for blocking instead.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I get:

Error: uncaught exception: [Exception... "Component returned failure code: 0x8055001a [nsIMsgCopyService.CopyFolders]"  nsresult: "0x8055001a (<unknown>)"  location: "JS frame :: chrome://messenger/content/folderPane.js :: ftv_drop :: line 477"  data: no]

with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090806 Lightning/1.0pre Shredder/3.0b4pre

I wonder if it's the same bug.

Comment 4

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090806 SeaMonkey/2.1a1pre] (home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/5c913c4662d8 + bug 444021 patch
 +http://hg.mozilla.org/comm-central/rev/4344cc9a28a7)

Bug still there.


(In reply to comment #3)
>  location: "JS frame :: chrome://messenger/content/folderPane.js :: ftv_drop ::
> 
> I wonder if it's the same bug.

I guess it could be the "non-rdf" version of the same issue, yes.


*****

(In reply to comment #2)
> The wanted flag doesn't apply to real bug, only to features that have higher
> priority and need special tracking. Real bugs should be nominated for blocking
> instead.

Well, blocking on this seems unlikely;
wanted is more like "would be good to fix the reported error".

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #4)
> (In reply to comment #3)
> >  location: "JS frame :: chrome://messenger/content/folderPane.js :: ftv_drop ::
> > 
> > I wonder if it's the same bug.
> 
> I guess it could be the "non-rdf" version of the same issue, yes.

Maybe asuth / Joey knows.

Comment 6

[Joey Minta]

At least in the thunderbird version, this "error" is simply the return value of nsIMsgCopyService::CopyFolders.  The confirmation prompt is internal to the local-folders implementation http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsLocalMailFolder.cpp#1081 and if the user doesn't click 'ok', we'll get a non-NS_OK response bubbled up.

There's not much the front-end can do at this point, other than simply wrap the call in a try/catch to hide the error. (That's a pretty trivial patch if people want it.) However, throwing the error as we currently do should not be harmful in any way.

Comment 7

[Robert Kaiser]

Any exception fix is nice to have, so I'll wanted+ it just so that an eventual fix has an easier path into the tree. As we could survive testing for a year without this causing a problem, and some analysis here might indicate it's something we should just mute with a try/catch, we'll not block the release on it, though.

Comment 8

[Robert Kaiser]

If it's a non-error basically, then I think we really should hide it with a try/catch to not make people believe there is an actual error (e.g. when debugging something else).

Comment 9

[Serge Gautherie (:sgautherie)]

(In reply to comment #8)

I usually dislike exceptions, but I believe this case is rare enough that I prefer to wait for bug 507601 first:
I suggest to simply move this to SM 2.1.