374801 - RFE: Ctrl+Shift+L as keyboard shortcut to forward message: toggle inline vs. attached

Status: RESOLVED WONTFIX

(Thunderbird :: Mail Window Front End, enhancement)

Description

[Thomas D. (:thomas8)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Version 1.5.0.10 (20070221)

There is a number of RFEs complaining that once you have set your prefs for forwarding either inline or attached in TB 1.5, it is very uncomfortable (but often needed!) to change the forward behaviour for a single mail. I personally find it very strange(!), too, that I cannot access "Forward as attachment" from context menu of single msg if my prefs are set to "Forward inline", so that I am forced to use the main menu: Message > Forward As > Attached.  Bypassing the age-old discussions about restructuring menus and having dual/drop-down buttons for reply, attach etc. (e.g. Bug 236833), I am hereby proposing a very moderate and simple, yet significant improvement over the status quo:

Please add Ctrl+shift+L as a shortcut for the alternate forward behaviour depending on user prefs:
If user prefs are "Forward inline":
   Ctrl+shift+L => Execute command "Forward as attachment"
ElseIf user prefs are "Forward attached"
   Ctrl+shift+L => Execute command "Forward inline"

I believe this will be very intuitive for users, as <shift> is often used by TB to modify a given command (ctrl+r = reply vs. ctrl+shift+r = reply all etc., check http://www.mozilla.org/support/thunderbird/keyboard and look at ctrl+enter, ctrl+u, ctrl+t with/without <shift>)

Correct me if I'm wrong, but I also believe this will be rather easy to implement, since in TB 1.5, ctrl+L is already able to reflect the user's forwarding pref, so I imagine that implementing ctrl+shift+L simply means swapping the respective commands, so that they reflect the opposite of user's forwarding pref.

At a later stage (and probably more difficult to do), it would be nice if the shortcuts would also correctly be displayed on the "Message > Forward > Inline | Attached" menus, as has been proposed in 2004 by Mike Cowperthwaite in description of Bug 236833.


Reproducible: Always

Steps to Reproduce:
1. Set user prefs to "Forward messages: Inline"
2. On a given single message, try to intuitively "forward as attachment"
(a) using keyboard shortcut ctrl+shift+L
(b) using context menu
Actual Results:  
(a) ctrl+shift+L does nothing (not assigned)

(b) context menu entry for the opposite of user's forwarding pref is (deliberately?) missing: In my case, missing context menu for "forward as attachment". There is only single "Forward" context menu entry (which btw leaves me guessing what kind of forward this currently is). According to user's prefs, in my case, "forward" will only "forward inline"



Expected Results:  
(a)ctrl+shiftl+L should forward selected message(s) using the OPPOSITE of the currently set user pref for forwarding (inline vs. attached):
If user prefs are "Forward inline":
   Ctrl+shift+L => Execute command "Forward as attachment"
ElseIf user prefs are "Forward attached"
   Ctrl+shift+L => Execute command "Forward inline"

(b) (this is another RFE, completely independent of (a)!) both forwarding methods should be somehow made available in context menu. Easiest, least clutter and most intuitive IMO would be to scrap "Forward" menu and replace with "Forward > Inline | Attached" popup menu. ctrl+L, as in current implementation, continues to invoke forwarding method according to user pref setting.

Comment 2

[Thomas D. (:thomas8)]

Sorry, but I DID have a very close look at bug 254931 before filing this as a separate bug and while they might be similar, they are definitely not duplicates (judging from TB 1.5 current behaviour).

Bug 254931 exclusively looks at using <shift> as a modifier when selecting "Forward" from a menu. In that case, <shift> ***toggles the composer mode (plain text vs. html)***. That toggling doesn't work if "forward attachments inline" user pref is set.

However in /this/ bug, I am talking about the keyboard shortcut for ***toggling between forward inline vs. forward attached***, which is a completely different thing (whether it SHOULD be a completely different thing with respect to ui consistency, is a different question, please read on).

Please look at the current behaviour with "reply" to see what I mean:
1.) Shortcut behaviour...
- ctrl+r => reply to sender
- ctrl+<shift>+r => reply to all
With the shortcut, <shift> toggles between two different reply commands (to sender vs. to all)

2.) versus (!) menu behaviour...
(applies to menu "Message > reply", msg context menu "reply", toolbar button "reply"):
- click "reply" => reply to sender with whatever *composition mode* is set/default in the given situation (e.g. html)
- click <shift> "reply" => reply to sender (!) with the /alternate/ composition mode of whatever composition mode is default in the given situation (e.g. text-only)
With the menu/toolbar button, <shift> toggles /another/ aspect of reply, namely text type / composition mode (text vs. html). This has nothing to do with the shortcut toggling between "reply to sender" vs. "reply to all."

Unless you intend to abolish the two different behaviours <shift+R> vs. <shift>+"Reply menu/button" as described above:

Requesting reopening of this RFE.

Comment 3

[Magnus Melin [:mkmelin]]

Ah, yes, confirming.

Comment 4

[Thomas D. (:thomas8)]

Are there any reasons against this shortcut, considering the perfect symmetry with ctrl+[shift]+r as outlined above?
If not, is there anyone out there willing to integrate the two lines of code needed for this shortcut for the sake of making alternating between forward(inline) vs. forward(attached) a little easier for users while certainly we will be waiting much longer for things like forward-button with dropdown functionality and context menu forward options to arrive?

Comment 5

[Thomas D. (:thomas8)]

Added Keyword, POLISH: "Bugs which require only a small change for a noticable improvement in the user interface"

In this case, it's about two lines of code change and notwithstanding future perfections like Forward Dropdown Button on Toolbar, context menu integration or even dynamic shortcut labels in the respective menus, just to have the shortcut only for the "other" method of forwarding would be great for a start - and it doesn't hurt or destroy anything... ;-)

Comment 6

[Magnus Melin [:mkmelin]]

I'm fairly inclined to wontfix this... seems just a waist of shortcuts.

Comment 7

[Magnus Melin [:mkmelin]]

->WONTFIX; we have a limited amount of hotkeys available...

Comment 8

[Thomas D. (:thomas8)]

I am accepting the decision, but I think the reasons are poor and therefore it should be reconsidered. One year later, the shortcut in question is still unused, and I am not aware of any plans to use it for something else.

(In reply to comment #6)
> I'm fairly inclined to wontfix this... seems just a waist of shortcuts.

Sure, we'd be wasting a shortcut that is currently unused and I bet so it will be for years to come...

(In reply to comment #7)
->WONTFIX; we have a limited amount of hotkeys available...

That's a non-argument as it applies to any new shortcut, even existing shortcuts, regardless of the value added.

I think the question should be: Are there any plans in the near future to use Ctrl+Shift+L for something else? If not, why not use it in a logical way as proposed in this bug, using the same approach as with Ctrl+Shift+R?

Even after implementing this (which shouldn't take more than 2 lines of code), you can still use this shortcut for something more important later on if that something actually comes along. So you aren't losing anything, on the contrary: In the meantime, some folks might appreciate a convenient workaround for the shortcomings of age-old bugs like Bug 17796 (Need dual menu buttons..., against Seamonkey), and, more recently, TB Bug 508250 (Provide "Forward as" options as drop-down button menu entries). And should you then decide to re-use that shortcut for something else somewhen in the future, you will have a better reason to make people unhappy than just "saving shortcuts" for nothing.

Comment 9

[Thomas D. (:thomas8)]

FTR: Ctrl+Shift+L currently used for "Reply to List" for mails which have a list recipient specified.