751433 - disable keyboard shortcut to delete attachment

Status: VERIFIED WONTFIX

(Thunderbird :: Message Reader UI, defect)

Description

[John]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

after clicking to read an attachment, press the Delete key on the KEYBOARD.


Actual results:

a box pop up reading "The following attachments will be permanently deleted from this message:..."


Expected results:

I just meant to delete the message, as it always did before.

I don't know whether that's related, but there was no such problem until recently, when thunderbird started to hide attachments in default view so you have to make an extra click to see the list of the multiple attachments.  The suggested solution appears to make a chrome entry (I won't comment here on why after a UI change users have to dig **** the internet to create a file they were never aware with a unfamiliar syntax in order to get back their familiar interface):

#attachmentView > [collapsed="true"] {
  visibility: visible !important;
}

#attachmentToggle {
  display: none !important;
}

then I started to observe the above problem of risking having attachments accidentally deleted in my mail.

Actually I will never want to delete attachments, is there a way to make sure the Delete key on the KEYBOARD always delete the message?

Comment 1

[John]

It's related to but not identical to https://bugzilla.mozilla.org/show_bug.cgi?id=702201

Comment 2

[Joe Sabash [:JoeS1]]

Maybe the same logic as in bug 702201 should apply to the delete key.
That is: we have a delete button in the dropdown, so the delete key should apply to the message and not depend on what is focused.

Comment 3

[Jim Porter (:squib)]

This would regress bug 315144, which is a dataloss bug. I'd argue fairly strongly that this should be WONTFIX. However, I'll let bwinton weight in first.

Comment 4

[John]

Talking about "dataloss" bug, the current situation is real dataloss, because when you accidentally delete the attachment, it is gone and non-reversible.  However if you accidentally delete the message, you know it's actually in the trash folder.

Since this is a consequence of the recent upgrade of TB that changed UI of many years' habit, at least a solution is needed to restore the old behavior.

Comment 5

[Jim Porter (:squib)]

About the only alternative that satisfies both cases would be to disable the delete key entirely when the attachment pane is focused, which I don't have a huge problem with, as attachment deletion is pretty rare.

If you'd like to restore the old behavior, it's straightforward to write an add-on to support this, but I don't think this will ever happen in Thunderbird core, since adding hidden prefs to revert every UI change would be a nightmare for testing and maintenance.

Comment 6

[Thomas D. (:thomas8)]

(In reply to Jim Porter (:squib) from comment #3)
> This would regress bug 315144, which is a dataloss bug. I'd argue fairly
> strongly that this should be WONTFIX. However, I'll let bwinton weight in
> first.

+1. I strongly agree with Jim that this should be WONTFIX.

(In reply to Joe Sabash from comment #2)
> Maybe the same logic as in bug 702201 should apply to the delete key.

The logic for bug 702201 was explained by Blake in Bug 702201 Comment 1:
> the rest of the buttons in the toolbar act on the message (or at least, not on
> the attachments)

Which was pretty clear case of ux-natural-mapping:
> controls should be placed in the correct location relative to the effect that > they will have.
That's a different issue than here.

> That is: we have a delete button in the dropdown, so the delete key should
> apply to the message and not depend on what is focused.

Absolutely NO. Please let's stop going down the road of disrespecting focus, we have tried that before and it's a dead end, especially when combined with dataloss risks (see my rants in bug 315144 if you need more detail).

There is really *nothing* unexpected about the fact that keyboard shortcuts will act only and exactly on the currently focussed element. Much more so for destructive keyboard shortcuts like DEL. It's unfortunate that Thunderbird disrespected this very basic rule of application design for so long (and still does, e.g. bug 308063) that some people have over time acquired wrong habits which are now being reclaimed in this bug. Don't take my word for it, verify from our very own design rules:

https://developer.mozilla.org/en/XUL_Tutorial/Focus_and_Selection

> The focused element refers to the element which currently receives input
> events. ... Only one element per window has the focus at a time.
> The user can change the focus by clicking an element with the mouse.

Applied to this bug:
1 single-left-clicking on attachment will select and focus it
2 focus (and selection) is on attachment -> attachment receives DEL key input, and should be deleted (-> wontfix for this bug)

There's a very simple reason why we need to respect focus (and wontfix this bug):
* internal ux-consistency within Thunderbird, and
* external ux-consistency with any other application or OS out there.
Things you click on will receive focus, and focus receives keyboard input. Deleting a selected and focussed attachment with DEL is no different in behaviour at all from deleting a selected and focussed file in Windows Explorer with DEL - especially given that our attachment UI is deliberately borrowing from the design of a file manager.

> That is: we have a delete button in the dropdown,

I'm not sure which "dropdown" this comment refers to, because the only dropdown I see that has a "Delete" command is the [Save (all)|v] button on attachment header bar. And *that* Delete command is always about deleting attachments, so that would be another point *against* this bug if anything.

(In reply to John from comment #4)
> Talking about "dataloss" bug, the current situation is real dataloss,
> because when you accidentally delete the attachment, it is gone and
> non-reversible.  However if you accidentally delete the message, you know
> it's actually in the trash folder.

You can't be serious. Really, how can you "accidentally delete the attachment"?

First, correctly following the principle of "focus takes keyboard input", it is impossible to delete an attachment using DEL key unless you've explicitly set the focus on it before.

Second, should you happen to hit DEL key *by accident* while focus happens to be on an attachment (and you're unaware), you'll get a confirmation dialogue before the attachment is permanently deleted. So that's covered (notwithstanding the potential desirability of UNDO for attachment deletion).

Third, if you *deliberately* pressed DEL with an intention of deleting the *whole* msg (rather than only the focussed attachment) because of wrong habit formation, you'll still get the confirmation dialogue (as a surprise because you don't usually get it for message deletion!). And then, why would you care to keep the attachment while you wanted to delete the *whole* message?

So this bug really is not about dataloss.
 
> Since this is a consequence of the recent upgrade of TB that changed UI of
> many years' habit, at least a solution is needed to restore the old behavior.

That's an understandable request, but I tend to agree with the response of Jim's comment 5:
> ...to restore the old behavior [somebody needs to] write an add-on...
> adding hidden prefs to revert every UI change would be a nightmare for testing
> and maintenance.
Certainly there's no obligation to keep providing old behaviour that is technically wrong as it disregards focus.

(In reply to Jim Porter (:squib) from comment #5)
> About the only alternative that satisfies both cases would be to disable the
> delete key entirely when the attachment pane is focused, which I don't have
> a huge problem with, as attachment deletion is pretty rare.

Not really: Disabling DEL key on focused attachments doesn't help either side.

* Disabling the DEL key when focus is on attachment(s), if anything, would satisfy only those users with wrong habit formation acquired from old versions of TB; for all other users with correct habits from virtually any other application out there, it will come as a surprise if DEL does *not* delete the focused object (here: attachment).

* Disabling DEL on focused attachment(s) would however punish users with correct focus habits for no reason:
- "traditional" users will not be happy because we don't delete the msg (which we can't, because of dataloss dangers only recently fixed by bug 315144).
- "traditional" users will not benefit an inch from disabling DEL because regardless if we delete the attachment or do nothing, they will still have to change their use patterns and move focus away from the attachment before they can actually delete the msg (which takes as little as e.g. a single click anywhere in message body).
- with DEL enabled for deletion of focused attachment(s), there is no risk of  dataloss for "traditional" users because if user intends to delete the *whole* msg, it wouldn't hurt to delete the attachment as a *part* of that msg, plus there's even a confirmation dialogue warning with precise information.

-> So why punish users with *correct* expectations about focus-keyboard interaction by "disabling DEL shortcut for deleting focused attachments" (as proposed by this bug) without any long-term benefit for other users?

Comment 7

[John]

Jim, I'm glad you are open minded above, I'd like to share an observation, I know an immediate change is impossible and obviously any change demands real work, but I figure it helps to let developers know some users' opinions.

I support and influence many people's desktop through various channels, since 0.3 or something I started to convert everyone to tb.  But in the recent year some "upgrades" would result in tons of time researching on the internet to restore the old gold obviously expected behavior of an email client.  

Take this delete key for example, I saw the very adamant arguments in the regress bug 315144 you provided above, they are all very sound in themselves - in the attachment pane obviously the delete key should delete the attachment!  That makes perfect sense to C++ developers, but let's face it, how many of the 6 millions TB users are C++ developers?  Almost all of them never thought of one could or want delete selected attachment in their mail.  So in the end the vote goes to the few elite programmers that's smart enough to discuss on bugzilla, versus the millions of average users that never heard of bugzilla.  But, it's only the latter that will count toward non-negligible market share by tb.

The same thing goes to the recent attachment pane change, I'm sorry Jim but no personal offence to you, to determine whether the change warrants reversion by counting downloads of the addon is somewhat flawed because, these UI problems can be hard to google so in my observation probably only one out of a hundred or maybe many more affected would be able to land on that page.  Like me I was seriously affected by that UI change but having to give up multiple times after finding no solution until one day I had to reserve a time slot and was determined to find out a solution before finding it after another hours of searching.  But pretty much everyone I know won't do that.  Most users just compare the available software and choose to use the one they like, they won't invest huge amount of time finding and installing addons.  These "upgrades" that cause huge user regression is very frustrating to users and will cost TB market share.  And besides it cost TB developers' time and effort to make these changes that may not needed in the first place.  

So my point is, maybe it would be worthwhile to determine UI change on the basis of average users not by developers.  A poll on the main download page may help but if that's too drastic at least you can consult your family members and average friends but definitely not diehard programmers.

Comment 8

[Jim Porter (:squib)]

(In reply to Thomas D. from comment #6)
> (In reply to John from comment #4)
> > Talking about "dataloss" bug, the current situation is real dataloss,
> > because when you accidentally delete the attachment, it is gone and
> > non-reversible.  However if you accidentally delete the message, you know
> > it's actually in the trash folder.
> 
> You can't be serious. Really, how can you "accidentally delete the
> attachment"?

It's quite easy: 1) Expand the attachment bar, which moves focus into the attachment list (I could see getting rid of this feature, but I forget why we added it originally, so maybe it's important for something), 2) hit delete, 3) don't read the confirmation dialog. Before you say that people *should* read the confirmation dialog, that's not actually going to happen. People just click past anything that causes ux-interruption.

> (In reply to Jim Porter (:squib) from comment #5)
> > About the only alternative that satisfies both cases would be to disable the
> > delete key entirely when the attachment pane is focused, which I don't have
> > a huge problem with, as attachment deletion is pretty rare.
> 
> Not really: Disabling DEL key on focused attachments doesn't help either
> side.

It prevents dataloss in a case where the effect of the delete key is unclear. It's made unclear because we *already* don't respect focus in all cases: if the folder pane is focused and a message is selected, we still delete the message when you hit the delete key. This is a good thing because deleting a folder is so much rarer than deleting a message, and anyway deleting folders often misbehaves on certain IMAP servers. Given that behavior, it's reasonable even for a new user to expect that the delete key ALWAYS deletes a message.

That said, I don't feel terribly strongly about this, except that we shouldn't support deleting messages with the delete key when the attachment list is focused.

Comment 9

[Jim Porter (:squib)]

(In reply to John from comment #7)
> Take this delete key for example, I saw the very adamant arguments in the
> regress bug 315144 you provided above, they are all very sound in themselves
> - in the attachment pane obviously the delete key should delete the
> attachment!  That makes perfect sense to C++ developers, but let's face it,
> how many of the 6 millions TB users are C++ developers?

This has nothing to do with being a (C++) developer, and everything to do with understanding how focus works. We could stand to improve this situation, since currently the Aero theme does a bad job of showing what's focused. However, there are a handful of keyboard shortcuts that conventionally apply to whatever has focused, and the delete key is one of them. It's perfectly reasonable for a person to expect that the delete key could be used to delete an attachment, since the UI is explicitly designed to look like a mini-file explorer. (It's also perfectly reasonable for a person not to expect this, since most other clients don't support it.)

> The same thing goes to the recent attachment pane change, I'm sorry Jim but
> no personal offence to you, to determine whether the change warrants
> reversion by counting downloads of the addon is somewhat flawed because,
> these UI problems can be hard to google so in my observation probably only
> one out of a hundred or maybe many more affected would be able to land on
> that page.

Take that up with bwinton. I've suggested to him a couple of times that we add the option to expand the pane by default, but he believes that not enough people would want to do this to warrant the additional complexity. (But see below.)

> So my point is, maybe it would be worthwhile to determine UI change on the
> basis of average users not by developers.  A poll on the main download page
> may help but if that's too drastic at least you can consult your family
> members and average friends but definitely not diehard programmers.

We already have Test Pilot and have run a couple of studies with it. We could certainly run more studies, but that takes time to develop and test them. Test Pilot studies are a good way to analyze places where Thunderbird's UX doesn't fit users' expectations, and I'm sure actual numbers would help convince bwinton or I. However, there are a lot of other studies that I think would be higher-value than one about this bug or the attachment pane being collapsed, so it might be a while before we studied those issues.

Comment 10

[John]

I see people compare deleting attachments in email client to deleting files on file manager, but are you sure that's a fair comparison?  A more direct comparison is to other email clients, such as to Outlook that has the highest market share among email clients.  Outlook does have menu to delete attachment, but it doesn't have a keyboard shortcut for deleting attachment at all, pressing Delete key will delete the message, it's a habit inherited by all other email clients that I am aware.  Someone can try this on other email clients such as apple mail etc and see how they are doing.  If only tb is pushing to drive users away from this decades of  habit then it's very telling of the situation.

Comment 11

[John]

Let me put it in another way, security and efficiency etc is another story, but talking about user interface, who understands it better?  Microsoft/Apple, or a few tb developers?  I feel tb can just focus on its strength and follow other guys on their strength, this will save developer resources AND deliver the product from the best of both worlds.

Comment 12

[Jim Porter (:squib)]

(In reply to John from comment #11)
> Let me put it in another way, security and efficiency etc is another story,
> but talking about user interface, who understands it better? 
> Microsoft/Apple, or a few tb developers?  I feel tb can just focus on its
> strength and follow other guys on their strength, this will save developer
> resources AND deliver the product from the best of both worlds.

Personally, I'm not likely to be swayed by an appeal to authority, especially given some of the UI Microsoft puts out (Outlook included). The same applies to Apple (they tend to rely over-much on skeuomorphism these days).

The question that needs to be answered is "What do users expect?", and we have the means to study this (either via Test Pilot or some other means). If it turns out that the vast majority of users expects the delete key to always delete a message, so be it. Likewise if they expect it to delete the attachment. If the results are split, then we should probably just disable the delete key entirely in the attachment pane to avoid confusion, or come up with a good way to train users.

Comment 13

[Mike Conley (:mconley) (:⚙️)]

My position is that this is a WONTFIX.  The delete key should mean to delete the selected / focused item.  Thus, if an attachment is selected and focused, it should try to delete the attachment.

Deleting the parent (in this case, the message) is unexpected and kind of awkward.

Comment 14

[Thomas D. (:thomas8)]

(In reply to Jim Porter (:squib) from comment #8)
> (In reply to Thomas D. from comment #6)
> > (In reply to John from comment #4)
> > > Talking about "dataloss" bug, the current situation is real dataloss,...
> > You can't be serious. Really, how can you "accidentally delete the
> > attachment"?
> 
> It's quite easy: 1) Expand the attachment bar, which moves focus into the
> attachment list (I could see getting rid of this feature, but I forget why
> we added it originally, so maybe it's important for something), 2) hit
> delete, 3) don't read the confirmation dialog. Before you say that people
> *should* read the confirmation dialog, that's not actually going to happen.
> People just click past anything that causes ux-interruption.

A three-step operation to arrive at "accidental dataloss"?
Plus, your steps don't work (fortunately):
1) Expand attachment bar
-> moves focus ring onto first attachment, but does *not* select that attachment
2 [review]) hit DEL
-> nothing! (correctly as expected, because only things that are focused *and* selected should be deleted; and since focus is already down in attachments, we can no longer safely assume users intention of deleting the message).

So the fact remains that you have to explicitly *select* (and thus also focus) an attachment before DEL applies.

> It prevents dataloss in a case where the effect of the delete key is
> unclear. It's made unclear because we *already* don't respect focus in all
> cases: if the folder pane is focused and a message is selected, we still
> delete the message when you hit the delete key. This is a good thing...

That's Bug 729731, indeed arguably a good thing because it *really* prevents *accidental* (read: unintended) dataloss.

> we *already* don't respect focus in all cases

Jim, are there any other cases where we don't respect focus with respect to DEL?
I don't think so but I'm eager to learn about them :)

> Given that behavior, it's reasonable even for a new user to expect that the
> delete key ALWAYS deletes a message.

No. In agreement with Mike's comment 13, it can never be reasonable to abuse a key as universal and versatile as DEL to delete the parent without confirmation when the child has focus and is itself deletable as a part. Really. Never ever. *Perhaps* with a modifier (Ctrl+Del), or confirmation (with the potential disadvantages mentioned by Jim).

There's an important difference between this bug (which is essentially a dupe of bug 315144) and the current behaviour of Bug 729731:

Deleting the selected message when focus is on parent folder means:
Deleting the *child* (the msg) when the parent (the folder) has focus, and user hits DEL. That's indeed a protection against accidental major dataloss, which is why I have not yet commented there in spite of the violation of focus (tricky!).

This bug (comment 0) requests *the other way round*: Delete the *parent* (the msg) when the *child* (the attachment) has focus, and user hits DEL. It's clear we cannot delete the parent (prevent dataloss); but there is no problem about the current behaviour of deleting the small child (attachm.), when the only other intention of a *deliberate* DEL keypress could be deleting the big parent (msg).

> It prevents dataloss in a case where the effect of the delete key is unclear.

No. Dataloss always implies *unintended* dataloss (because *intended* dataloss is *deletion*). When a user expects to delete *the message* by pressing *DEL* while attachment is focused, the intention is obviously deleting the msg *including the attachment*. So deleting *only the attachment* cannot be dataloss, because it's part of the *intended deletion* of the *whole message*.

*Non-intentional* (accidental) DEL keypress on attachment (without any intention of deleting anything) is covered by confirmation dialogue. Unfortunately, we cannot protect users against ignoring confirmation dialogues, or against their cat jumping on the keyboard.

> a case where the effect of the delete key is unclear.

Per Mike's comment 13...
> delete key should mean to delete the selected / focused item.
> Deleting the parent (in this case, the message) is unexpected & kind of awkward
...and Jim's comment 9...
> "UI is explicitly designed to look like a mini-file explorer"
...I conclude it can't be very unclear that pressing DEL on a selected and focused thing will delete that thing (as it would in any file manager).

As explained in my comment 6, the so-called compromise of "making DEL do nothing" is not helpful either way:
* users like reporter who expect DEL to delete the message will still have to move focus away from the attachment in order to delete the msg (and they will be robbed of the chance to learn from the attachment deletion confirmation dialogue that it doesn't work because they are actually deleting only the attachment).
* users with a correct notion of focus will fail with a correct and established use pattern (and again, no way of telling them why).

Iow, keeping attachment deletion enabled (as we currently do) will *not* hurt msg deletion users more than just doing nothing, but help them (via the confirmation dialogue) to understand *why* we do not delete the message when focus is on attachment. So unless we intend to reverse bug 315144 and re-introduce the respective dataloss scenarios, like it or not, both types of users will be better off with the status quo.

Comment 15

[Thomas D. (:thomas8)]

(In reply to Mike Conley (:mconley) from comment #13)
> My position is that this is a WONTFIX.  The delete key should mean to delete
> the selected / focused item.  Thus, if an attachment is selected and
> focused, it should try to delete the attachment.
> Deleting the parent (in this case, the message) is unexpected and kind of
> awkward.

That's 3 votes for WONTFIX (Jim, Mike, and me).

Comment 16

[Thomas D. (:thomas8)]

(In reply to John from comment #0)
> I just meant to delete the message, as it always did before.

John, in spite of my adamant comments in this particular case I do sympathize with the pain inflicted by breaking of formed habits, especially in cases where there are easy and obvious solutions to avoid that pain. But sometimes we have to choose the lesser of two evils, and guarding against unintended dataloss is a very high value, while the resources of a small TB developer team to make all users happy by keeping all things legacy are very limited.

> I don't know whether that's related, but there was no such problem until
> recently, when thunderbird started to hide attachments in default view so
> you have to make an extra click to see the list of the multiple attachments.

Yes, technically these are related, iirc introduced by bug 630759 (and perhaps some other bugs based on that). Jim did a great job in addressing all sorts of problems of attachment pane (e.g. keyboard accessability) and adding helpful features (e.g. attachment sizes).

John, I completely agree with you that forcing attachment pane to start collapsed is a foreseeable UX painpoint that could rather easily be addressed by incorporating the functionality of Jim's addon into core. Fwiw, you'll find my  adamant support for that issue in my comments on Bug 647036, as well as my arguments and those of others why offering addons as a fix for basic usability issues is a problem, and why counting addon downloads or doing Test Pilot studies doesn't really help, either.

Comment 17

[John]

(In reply to Thomas D. from comment #15)
> (In reply to Mike Conley (:mconley) from comment #13)
> > My position is that this is a WONTFIX.  The delete key should mean to delete
> > the selected / focused item.  Thus, if an attachment is selected and
> > focused, it should try to delete the attachment.
> > Deleting the parent (in this case, the message) is unexpected and kind of
> > awkward.
> 
> That's 3 votes for WONTFIX (Jim, Mike, and me).

Sorry it took me days to think over this.  But it's a question of how to define the direction of user interface, by three tb programmers, or by dozens of years of all user habit and all other companies like Apple/Microsoft that invest dearly in studying UI.  A few weeks ago firefox displayed a video upon upgrading, saying mozilla differs than others by focusing on user's choice (something like that), how do you relate that to your handling of these decisions?

One solution to this particular problem, is to not highlight the attachment at all, thus the Delete key always delete the attachment.  Actually tb already does this when there is only one attachment.  It appears to highlight that attachment when you click it, but as soon as you move mouse away, it gets de-highlighted.  Apparantly someone realized that is the expected behavior anyway.  Doing that to the case of multiple attachments will restore the consistency of that interface.

Comment 18

[Jim Porter (:squib)]

(In reply to John from comment #17)
> (In reply to Thomas D. from comment #15)
> > That's 3 votes for WONTFIX (Jim, Mike, and me).
> 
> Sorry it took me days to think over this.  But it's a question of how to
> define the direction of user interface, by three tb programmers,

Thomas D is (as far as I know) not a TB programmer, and just a long-time Thunderbird user who volunteers to help with bug triage. I think it would be safe to say that he's approaching this from a user context.

While there are things we could do to improve the behavior here (e.g. allowing undo when you delete an attachment), the user must explicitly click on an attachment in order for the delete key to delete it.

As mentioned above, a user who selects an attachment and presses the delete key to remove it would be very surprised to see the message go away entirely. This action can be undone, but likewise, deleting an attachment requires the user to confirm it, which should indicate pretty clearly that you're not deleting a message, since that doesn't open a confirmation dialog.

> A few weeks ago firefox displayed a video upon upgrading, saying mozilla differs than
> others by focusing on user's choice (something like that), how do you relate that to
> your handling of these decisions?

"User choice" doesn't imply that every behavior needs a preference to disable/modify it. Every option we add to Thunderbird has a maintenance and support burden, so we as developers must be cautious when adding options. In any case, part of keeping users in control is letting people write add-ons to do whatever they want in Mozilla applications.

Based on the above votes from Thomas and Mike, I'm going to close this as WONTFIX, though I'm certainly open to other options (e.g. providing a dedicated "delete message" command for add-on authors to hook into) to help clarify this behavior, so long as we keep said behavior intact.

Comment 19

[John]

(In reply to Jim Porter (:squib) from comment #18)

> As mentioned above, a user who selects an attachment and presses the delete
> key to remove it would be very surprised to see the message go away
> entirely. This action can be undone, but likewise, deleting an attachment
> requires the user to confirm it, which should indicate pretty clearly that
> you're not deleting a message, since that doesn't open a confirmation dialog.
> 
The question is how many more are very surprised that, after opening an attachment and then press Delete key to delete the message, are surprised to find a pop up box prompting to permanently delete the attachment instead.  If you post a poll on the home page of Mozilla, I'm sure at least twice people will be surprised in this way.  If you say fine then these users should write their own addon, then that's how tb goes nowadays.