542723 - (Tb 3.0.1) If appending to IMAP offline-store file is interfered by other software, mail copy/move to the IMAP folder silently fails ([nsIMsgCopyService.CopyMessages] nsresult:0x80004005)

Status: NEW

(MailNews Core :: Database, defect)

Description

[WADA:World Anti-bad-Duping Agency]

+++ This bug was initially created as a clone of Bug #501851 +++

Phenomenon of test case of bug 501851 is changed by Tb 3.0.1.
If appending to IMAP offline-store file is interfered with other software, mail copy/move to the IMAP folder silently fails.
Following error message was issued at error console.
> Error: uncaught exception: [Exception... 
> "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
> [nsIMsgCopyService.CopyMessages]" nsresult: "0x80004005 (NS_ERROR_FAILURE)"
> location: "JS frame :: chrome://messenger/content/folderPane.js :: ftv_drop :: line 589"  data: no]

[Build ID]
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1

[Steps to produce]
(1) Folder-X contains some mails.
(2) Open offline-store file(Folder-X) by external program(I used Sakura Editor)
(3) Copy(or move) some text/plain mails to IMAP folder Folder-X,
(4) open Folder-X. Nothing is copied(or moved).

Comment 1

[mikedoo3]

I can confirm exactly what you say.  I opened the offline file in MS Word and got the same error.  This was in Thunderbird 3.1.10 on Windows.

I actually was looking for that exact error posted in the details.  I have customers getting that same exact error message with Thunderbird 3.1.10 on Linux, connected to an MS Exchange 2003 IMAP server.  When it happens to them, they drag a message to an IMAP folder and it looks like nothing happens.  They click the folder they dragged the message to, click another folder, then come back to the folder they dragged the message to and the message they tried to drag there appears there but with mismatched header/body (Repairing the folder fixes it).  Thunderbird 2 never acted this bad.

Comment 2

[Wayne Mery (:wsmwk)]

Do we have any candidate ideas to move this forward?  retry?

Comment 3

[Kent James (:rkent)]

(In reply to Wayne Mery (:wsmwk) from comment #2)
> Do we have any candidate ideas to move this forward?  retry?

Let me interpret this question narrowly as "what would it take to get rkent to take on this bug, and try to fix it?"

Has the triage been fully completed? Looking I see several remaining issues. First, it would be good if there was an independent confirmation that the STR in comment 0 actually work, and that they result in the dataloss described in comment 1. Second, let's define success. Is it silently failing with no dataloss? Is it showing an alert dialog? Is it caching the request to automatically succeed later? (Probably giving an alert is correct).

Once the triage is complete, the next issue becomes "is this the bug I should work on?" If fully triaged and reproducible, this bug is clearly solvable without major rework, but is not trivial. I have the capacity to handle about 2 bugs per month of this complexity. It would be nice if someone with the stature of a wsmwk or WADA would say "rkent, I'd like to suggest this bug as one I think is most important for you to take on next".

But this is probably a lot more than you were asking!

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to Kent James (:rkent) from comment #3)
> (In reply to Wayne Mery (:wsmwk) from comment #2)
> > Do we have any candidate ideas to move this forward?  retry?
> 
> Let me interpret this question narrowly as "what would it take to get rkent
> to take on this bug, and try to fix it?"

actually, I am only fishing for ideas at this point, for which I am grateful, because this bug and it's nasty ilk have stagnated

> Has the triage been fully completed? Looking I see several remaining issues.
> First, it would be good if there was an independent confirmation that the
> STR in comment 0 actually work, and that they result in the dataloss
> described in comment 1. Second, let's define success. Is it silently failing
> with no dataloss? Is it showing an alert dialog? Is it caching the request
> to automatically succeed later? (Probably giving an alert is correct).

unsure re: comment 1 whether a) there is dataloss (or something looking like it) or b) that this is a regression from version 2.  Surely wada's comments can be trusted, except for the passage of time. But on these and other points I will defer to others ATM.

Comment 5

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.