516240 - Message > Archive does not work for .eml files or emails from attachments (cannot use archive command, doesn't do anything) - Minimal fix: disable Archive where it doesn't work

Status: RESOLVED FIXED

(Thunderbird :: Message Reader UI, defect)

Description

[Thomas D. (:thomas8)]

For mail messages opened from a .eml file or emails from attachments, Message > Archive command does not work. IMO, it should work. This is the opposite request of Bug 489001, which wants to disable that command. I don't see why. Let the user archive an email from anywhere, if he so wishes.

Comment 1

[Thomas D. (:thomas8)]

Whereas similar Bug 193281 focusses on the Message > Copy command, this bug 516240 is specifically about the Message > Archive command.

Comment 2

[WADA:World Anti-bad-Duping Agency]

"Archive" is "mail move of mail(s) in a mail folder to Archives folder".
"Archive" is never "import/save/... to Archives folder".

(1) For ".eml" which is displayed in standalone window or tab. 
    I think ".eml" case should be covered by Bug 193281 etc.
      Save as mail, Import, Drag&Drop, ...
    AFAIK, implementation of "Drag&Drop  of .eml to mail folder" is in progress,
    although it's still "in progress" (Bug 171907 is fixed, so Drag&Drop itself
    works with Tb trunk, but data in mail folder file is still corrupted.)
(2) For attached mail which is displayed in standalone window or tab.
    Which mail is target mail of "Archive"?
    a) Main/parent mail of the attached mail.
    b) The attached mail which is displayed in the window or tab.
    If a), I think "Archive" is applicable, confusing though.
    But if b), I think it should be similar to ".eml". although "save in
    Archives and detach it from main mail" can be called an "Archive operation".
    However, if deeply nested mail, and if this "Archive" is executed at multiple
    nesting level, tracking of "archiving" is nearly impossible...

Are you requesting functionality of "import/save of .eml/attached mail" to "Archive" feature?

Comment 3

[WADA:World Anti-bad-Duping Agency]

Oh, Bug 489001 already exists.
> Bug 489001 : archive is not disabled for .eml files  
(Copy of Bug 489001 Comment #2)
> Well bug 516240 is the reason this is a bug.
> And bug 516240 should be duped to the bug about being able to save .emls to
folders - which is a real old one.

Thomas D., please remove "archive" from bug summary to avoid misleading.
Enhancement requests for save, import, drag&drop etc. for attached mail/.eml are a lready exist. See dependency tree for meta Bug 269826, please. ("Show resolved" to see already implemented ones.)
Setting dependency of Bug 269826 for ease of tracking.

Your bug looks comprehensive request for all functionalities.
How about changing this bug to meta bug for it?

Comment 4

[Thomas D. (:thomas8)]

(In reply to comment #2)
> "Archive" is "mail move of mail(s) in a mail folder to Archives folder".
> "Archive" is never "import/save/... to Archives folder".

I see what you mean, but that's prescriptive and splitting hairs. The user doesn't know the scientific difference of concept, and you won't be there to explain when users get frustrated that things are disabled for no apparent reason. For the user, "Archive" just means "put this message I see into my Archives folder". But even developers don't seem to have that clear line in their concepts, just look at the current summary of active Bug 193281:

> Ability to import e-mail messages from .eml text files to folders
> (Message|Copy)

So the fix for that bug will re-enable the "Message > Copy to..." command.
An interesting observation to make in TB2 is that while some commands are disabled (including the "Move to..." command), "Copy to..." isn't. So developers went for a healthy compromise between conceptual strictness and user comfort (which involves a slight fuzziness of the concept). With a strictly theoretical concept, you might say: "Copy to..." is "mail copy of mail(s) from a mail folder to some other folder". But again, users don't think that way. They think "Copy is putting this message into some folder while keeping the original" - which is exactly what "importing" a .eml file is about.

You can easily test why users think that way: Tell a friend to open three messages in standalone windows (don't watch): one from your inbox, another one from a .eml-file on your disk, and a third one from an .eml-file that came as an attachment. Now you tell the difference. There isn't any. They all look like "a message". Therefore, users expect they can act on it as they would with any other message from within their mail folders.

btw. Magnus Melin has just adjusted the summary of Bug 489001:
> Archive is not disabled for .eml files (which should be *until it can work*)
Apparently to him, too, there's nothing wrong with archiving .eml files. Let's put it the other way round:
1) What are the benefits of allowing "archive" on .eml?
2) Are we doing something wrong like adding complexity or violating UI concepts?

1) Benefits: User sees message that looks like any other message. User can use same patterns as he would with any other message. User has direct way to archiving .eml message (from file/from attachment), which is a valid scenario.

2) Checking disadvantages: Most other message-related commands are enabled: reply, forward, etc. Interestingly, "Archive..." is among them and NOT among the "Move/Copy to..." group of advanced commands. We'd probably add rather than reduce complexity by disabling "Archive...". User won't expect that we delete external .eml file. We never do. We don't seem to violate any UI concepts.

> (2) For attached mail which is displayed in standalone window or tab.
>     Which mail is target mail of "Archive"?
>     a) Main/parent mail of the attached mail.
>     b) The attached mail which is displayed in the window or tab [...]
>     However, if deeply nested mail, and if this "Archive" is executed at
>     multiple nesting level, tracking of "archiving" is nearly impossible...

Aren't you overcomplicating this a bit? Just have a look at the current implementation, which is clearly b). Anything else would be insane. We're looking at the attached .eml file, and that's what we're acting on (yeah, I know TB devs don't like acting on focussed elements...) Again, all other message-related commands are enabled and they also work. Try reply to an attached .eml that you have open in a standalone window. It just works as it should. And so should Archive.

You are right, user MIGHT expect that we detach on "Archive" operation. But it won't hurt if we don't. If we get complaints, than that's a case for "Detach and archive", and not a case against "Archive" per se.

> Are you requesting functionality of "import/save of .eml/attached mail" to
> "Archive" feature?

For the aforementioned reasons, yes.

(In reply to comment #3)
> Thomas D., please remove "archive" from bug summary to avoid misleading.
> Your bug looks comprehensive request for all functionalities.
> How about changing this bug to meta bug for it?

For the same reasons, I cannot remove "archive" from this bug's summary as that's what this bug is about. But I'll try to make it clearer and more specific. It's not meant to be a meta bug.

Comment 5

[Thomas D. (:thomas8)]

Sorry for "wall of text", it just so happens when working through the details...

Comment 6

[WADA:World Anti-bad-Duping Agency]

After implementation of bug 171907(drag&drop of .eml on mail folder), bug 498978 and bug 499304 were fixed, then "drag&drop of .eml on mail folder" of Tb3 latest nightly successfully imports .eml file to mail folder if local mail folder(I didn't check IMAP case yet.)
So, "archive, save in folder, ...,  at .eml file window" can be implemented easily than before.

Comment 7

[Jim Porter (:squib)]

Now that you can copy an .eml message via Message -> Copy To, should we still leave this bug open? I don't really agree that this is wanted, since it leads to confusion about what should happen to the .eml. Should we delete it? "Archive" is, after all, a move operation, not a copy operation. (I'd argue we shouldn't delete it, and we shouldn't encourage conflation of move and copy commands.)

Comment 8

[Thomas D. (:thomas8)]

Wayne, Ronald, Magnus, opinions?

(In reply to Jim Porter (:squib) from comment #7)
> Now that you can copy an .eml message via Message -> Copy To, should we
> still leave this bug open? I don't really agree that this is wanted, since
> it leads to confusion about what should happen to the .eml. Should we delete
> it? "Archive" is, after all, a move operation, not a copy operation. (I'd
> argue we shouldn't delete it, and we shouldn't encourage conflation of move
> and copy commands.)

While I wouldn't go to war for keeping this open (I'm not using Archive myself), I'd still argue that advantages (efficiency) outweigh disadvantages (slight fuzziness of concept).

1) I think, "copy external .eml to Archive folder" and "copy (or move) attached .eml to Archive folder" are valid and plausible usecases. Not for millions of users, but for those who actually have .eml files inside or outside TB.

2) Jim is right that at least for the external .eml, we cannot delete it if we allow "Archive" command. Therefore, strictly speaking, there is a slight fuzziness of concept because usually archive is "move to" but in this case it's more like "copy to" command. However, it's still "copy *to Archive*"! For the attached .eml case, we may or may not opt for detach.

3) For users who want usecase of 1) ("I want this .eml to be in my Archive"), compare the Workflow:

a) with Archive command *disabled* on external or attached .eml's:
user needs to use "Copy to" command, which is only available through menu (no keyboard shortcut unless repeatedly used with Ctrl+Shift+M):
- Message > Copy To > Account > Archive
That's a complex mouse action with 4 click targets, and at least the last two require a lot of attention not to miss them and are not keyboard accessible.
So while conceptionally 100% correct, this is highly *inefficient*.

b) with Archive command *enabled* on external or attached .eml's:
- press A -> done! And perfect for my muscle memory.
(Although for external .eml, I'm not 100% sure how to determine the account whose Archive folder we should use: recipient's mail address or currently focused account?)
So while conceptionally slightly fuzzy, this is highly *efficient*.
If you don't like it, don't use it. Those who like it will certainly appreciate the comfort and no-brainer speed. And it doesn't do any harm even if your expectations are different: no dataloss or anything like that. We've had and still have much more confusing and dangerous behaviour in our UI for years, e.g. bug 374853.

Conclusion:
- I'd still think that benefits of b) outweigh a), in favour of this rfe.
- I don't have very strong feelings about this, and I see Jim's point, too.

What do others think?

Comment 9

[Wayne Mery (:wsmwk)]

I don't archive so I may be an unsympathetic person to comment.  skimming this, i'm persuaded to Jim's POV.

Comment 10

[Magnus Melin [:mkmelin]]

Yeah i'd lean towards not supporting it.

Comment 11

[Jim Porter (:squib)]

Currently, at least, we really *can't* support it (well):

1) For .eml files, there's no account, so we wouldn't know where to archive to. We'd have to guess (either use the default account, or try to find an account based on the From/To fields), and I'm not sure what people want here.

2) For attached emails, we can't copy them into folders yet, so archiving probably wouldn't work either. This will require some changes to nsIMsgCopyService. I can see an argument for supporting this eventually, but we'd still have the confusion about move (detach) vs copy.

In both cases, we could just expect the user to copy the message to any folder in the account, and then hit A to archive it. That's two steps, but unless there's one common use case for this (e.g. if 90% of people want to detach attached emails into their archive folder), I think we should relegate this to add-ons, so that people can make the archiving work the way they'd expect.

However, we should probably disable the archive button for these types of messages so that people don't get confused when it does nothing.

Comment 12

[Thomas D. (:thomas8)]

Bug 489001 has regressed. Archive command on external .eml file is no longer disabled on tb9.

Comment 13

[Magnus Melin [:mkmelin]]

Attachment: proposed fix

Just disable it for .emls.

Comment 14

[Jim Porter (:squib)]

Comment on attachment 667127 [details] [diff] [review]
proposed fix

Review of attachment 667127 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good! Sorry about the delay in reviewing...

Comment 15

[Magnus Melin [:mkmelin]]

https://hg.mozilla.org/comm-central/rev/a6632381290b -> FIXED