(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.

[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.

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.

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.

[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".

(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.

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.

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.

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).

(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.