1687452 - Fix further fallout from bug 1571672 (UTF8=ACCEPT) and follow-up bug 1686034: 1) Delete attachm. 2) ASSERTIONs 3) Archive 4) Move again 5) Filter action 6) Open attachment

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Klaus B.]

As mentioned in bug 1686034 comment #40, further fallout from bug 1571672 was expected.

On Gmail, create a folder called testé, store a message with an attachment into that folder. Delete the attachment:

First fault: Doesn't work.

JavaScript error: chrome://messenger/content/msgHdrView.js, line 3306: NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIMessenger.detachAllAttachments]

Create folders Drafté and Archivé. In the account settings, set those folders as archive folder and draft folder.

Second fault:

[Parent 14812, Main Thread] WARNING: NS_ENSURE_TRUE(browsingContext) failed: file c:/mozilla-source/comm-central/dom/base/Document.cpp:3706
[Parent 14812, Main Thread] ###!!! ASSERTION: fileName is not in UTF-8: 'mozilla
::IsUtf8(fileName)', file c:/mozilla-source/comm-central/comm/mailnews/base/src/
nsMsgDBFolder.cpp:2812
[Parent 14812, Main Thread] WARNING: NS_ENSURE_TRUE(mozilla::IsUtf8(nsDependentCString(aFolderURI))) failed: file c:/mozilla-source/comm-central/comm/mailnews/base/src/nsMsgUtils.cpp:479

Select a message and Archive.

Third fault:

Folder Archiv<?> is created, message is not archived.

Move something to folder testé. Right click on another message.

Fourth fault: Move to "test<?>" Again is displayed.

Create another folder testéé, create a rule to move a message into that folder.

Fifth fault: The folder "test<?><?>" could not be found ...

That's what I can see in five minutes of testing. I suggest to back out bug 1571672 and fix it properly.

Comment 1

[Klaus B.]

Not to forget bad folder names showing up: Bug 1686034 comment #37. And there is bug 1686415. The buggy "Sent folder" is likely similar to the buggy Archive folder.

Comment 2

[Klaus B.]

I've just noticed that the archive issue was already reported in bug 1685450 and erroneously closed a duplicate.

Comment 3

[gene smith]

I tried to just open an attachment (.jpg) displayed inline with the current trunk version having Ping/Klaus patches and I get some kind of error about /tmp file. I only see this on my folders with non-ascii chars. I'm pretty sure I did this a lot when I added/debugged the utf8=accept feature so I'm thinking this might be caused by the Ping/Klaus patches. I'll back them out, Klaus first then Ping, and see what happens...

Ok, backed out Klaus, no difference.
Backed out Ping. Now I can open attachments.

I suspect the observation about about unable to delete attachments works now too...

Tried it again. Now an attachment deletes with the changes backed out. With the changes still in, it didn't delete.

Comment 4

[Klaus B.]

Thanks for testing. So the changes from bug 1686034 fixed one thing and broke another? (The second patch was just cosmetic.) I call that "whack a mole" scenario, see bug 1571672 comment #93. The changes in bug 1686034 moved more APIs/IDLs to UTF-8. It's likely that there will be more of that needed. Likely the openAttachment()/detachAttachment() in nsIMessenger.idl as I pointed out previously. Without an concept/design/strategy, you'll be "spot fixing" for a while.

Comment 5

[Ping Chen [:rnons] (away)]

Attachment: Bug 1687452 - Fix save and delete attachment from non-ASCII IMAP folder. r=mkmelin

Comment 6

[Ping Chen [:rnons] (away)]

I tested just now, move again label and filtering will be fixed by bug 1687412, kudos to Ben.

Comment 7

[gene smith]

I stripped the two "backout" commits I created and applied the comment 5 patch and rebuilt.
Fixes the problems I identified in comment 3. (This effectively applies comment 5 patch on top of the Ping/Klaus patches.)

Regarding Klaus' test where he sets the archive folder to a folder with a non-ascii name. I definitely remember testing this with all the folder types that can have user defined location (sent, archive, trash, drafts, templates) and they all worked with non-ascii named folders. However with the patches applied as described in previous paragraph, setting a non-ascii folder name for archive wouldn't stick and the icon on the newly designed folder never changed. So again I reverted the patches above and it still didn't work. I remembered Klaus had indicated there was another patch that Ping did to change to AUTF8String for another problem: Bug 1685033. When I backed out that change, it worked again as I remembered. So I guess the fix for Bug 1685033 whacked one mole but another one popped up.

I'm not sure how Ben's fixes that Ping refers to above affects all this.

Anyhow, at this point I have only tested an alternate archive name (currently Skr-ሴ-äåæ-archive). I'll hold off further testing until the changes and patches stabilize some.

Comment 8

[Ping Chen [:rnons] (away)]

I sent a patch to fix archiving in bug 1685450.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/2029e2497d18
Fix save and delete attachment from non-ASCII IMAP folder. r=mkmelin

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/9ad418c0fb5e
Use AUTF8String for all folder attributes in nsIMsgIdentity. r=mkmelin

Comment 11

[Klaus B.]

Filed follow-up, bug 1687938.

Comment 12

[gene smith]

Updated to latest and re-built and problem observed in comment 7 is resolved. I'm now able to assigned folder with name like Skr-ሴ-äåæ-archive as the the archive destination, the folder icon changes appropriately and messages archived are moved to it and are accessible there in the correct "year" folder.