553387 - Reply/Forward via keyboard shortcut does not respect "shift" format override

Status: RESOLVED WONTFIX

(Thunderbird :: Message Reader UI, enhancement)

Description

[rocketraman]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US) AppleWebKit/532.9 (KHTML, like Gecko) Chrome/5.0.307.11 Safari/532.9
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

When replying to an email, one can hold down the Shift key while clicking the Reply button. This will override the format settings, and send in plaintext if format is HTML or vice-versa. Same for Forward.

However, when doing reply via the keyboard (Ctrl+r) or forward via the keyboard (Ctrl+l), the shift modifier is not respected. On my machine, Ctrl+Shift+r does the same thing as Ctrl+r and Ctrl+Shift+l does nothing recognizable.

[1] http://kb.mozillazine.org/Plain_text_e-mail_(Thunderbird)

Reproducible: Always

Steps to Reproduce:
1. Open an email.
2. Type Ctrl+Shift+r or Ctrl+Shift+l

Actual Results:  
Creates an email reply or forward in HTML (if HTML, or both, is default).

Expected Results:  
Creates an email reply or forward in plaintext (if HTML, or both, is default).

Comment 1

[rsx11m]

Per design, Ctrl+Shift+r is "Reply to all" and Ctrl+Shift+l "Reply to list", the Shift+Click behavior to use the opposite composition mode only applies to the toolbar buttons.

Comment 2

[rocketraman]

I see. What other keyboard shortcuts would make sense? Perhaps instead a shortcut to toggle the composition mode. The current mode could be shown in the status bar.

Comment 3

[rsx11m]

I can't come up with any suggestions, but toggling of the composition mode requires bug 216132 to be fixed before a keyboard shortcut can be defined.

Comment 4

[Martin von Gagern]

As bug #216132 comment #25 correctly states, reply-then-toggle would have problems if the default is plain text: then when you have pressed reply, the text is already converted to plain text and the original HTML of the message you reply to is lost.

You could of course keep the original HTML and use it as long as the user hasn't modified it. In that case, a conversion would work as intended just after composing, but would yield a different result if e.g. you already typed "Hello," before switching.

Comment #2 could also be read as a request for a toggle of state in the main TB window, as opposed to a toggle of format in the already opened message composer. That possibility is mentioned in bug #216132 comment #25 as well, but it's not addressed in that bug report. So it would be a new request, probably best filed as a separate report blocking this one here.

Comment 5

[rocketraman]

My comment #2 was off the cuff and probably not thought out well enough to bother implementing at this point, unless done as part of bug #216132 or related bug as suggested in comment #4. I created this bug simply to document a nice-to-have keyboard shortcut to duplicate the functionality of "Shift-click Reply" and "Shift-click Reply All". Unfortunately, the "obvious" candidates are already taken as per Comment #1.

Perhaps then this bug should not depend on bug #216132 after all, but since #216132 is related, it may be best to leave the dependency so that a consolidated solution can be reached.

Comment 6

[rocketraman]

Argh, Ctrl-Shift-R was re-assigned in TB10 to "Remove named anchors". At least reply-all made some sense given that Ctrl-R is reply.

Comment 7

[Jim Porter (:squib)]

(In reply to rocketraman from comment #6)
> Argh, Ctrl-Shift-R was re-assigned in TB10 to "Remove named anchors". At
> least reply-all made some sense given that Ctrl-R is reply.

That's just in the composer, and so doesn't apply here at all.

Comment 8

[rocketraman]

(In reply to Jim Porter (:squib) from comment #7)
> (In reply to rocketraman from comment #6)
> > Argh, Ctrl-Shift-R was re-assigned in TB10 to "Remove named anchors". At
> > least reply-all made some sense given that Ctrl-R is reply.
> 
> That's just in the composer, and so doesn't apply here at all.

Ah, ok. My apologies.

Comment 9

[Thomas D. (:thomas8)]

rocketraman (reporter), what's the way forward for this bug?

While I sympathize with the general idea of this bug (would be nice to have a keyboard-shortcut equivalent for shift+click for non-default format), I can't think of a feasible way of doing this:

- comment 0 (ctrl+shift+R and ctrl+shift+L for non-default format of reply/forward) is certainly *wontfix*, because "reply-to-all" and (arguably) "reply-to-list" can be assumed to be a far more frequent use case compared to non-default-format (so they deserve the most intuitive shortcuts)
- in general, imo non-default-format on a per-message basis (this bug) is no longer a very frequent usecase, even for those users who still use plain text: If you really want plaintext, you'll probably set that as a default in general, or in address book on a per-recipient basis.

So I'm not sure it's even worth looking for extra keyboard shortcuts for this rather infrequent use case, and I doubt anyone would bother to implement them.

So I think this bug should be closed *wontfix*.
(And if you still want to look for new keyboard shortcuts, it would be better to open a new bug for that instead of morphing this one.)

rocketraman, is that ok with you?

Comment 10

[rocketraman]

It would be great if Thunderbird had options to modify keyboard mappings, but until that mythical time, WONTFIX on this is fine.

Comment 11

[Thomas D. (:thomas8)]

rocketraman, have you tried Keyconfig Addon (1) which allows you to modify all keyboard mappings?

(1) http://kb.mozillazine.org/Keyconfig_extension

Closing wontfix per comment 9, acknowledged by reporter in comment 10.

Comment 12

[rocketraman]

Thanks for the pointer, I'll give it a shot. Can anyone assist with the correct entry in prefs.js for the reply plaintext command? According to the docs, it should have the following format:

user_pref("keyconfig.main.xxx_key__NAME", "!][][][FUNCTION");

Comment 13

[franc]

As my knowledge, with the Keyconfig Add-On it is not possible to assign a key for this. 
As I understand this Add-On it is not possible to modify the mouse-mappings, which needs to be done here.

Comment 14

[Jim Porter (:squib)]

(In reply to rocketraman from comment #12)
> Thanks for the pointer, I'll give it a shot. Can anyone assist with the
> correct entry in prefs.js for the reply plaintext command? According to the
> docs, it should have the following format:
> 
> user_pref("keyconfig.main.xxx_key__NAME", "!][][][FUNCTION");

You'd probably want this for replying as plain text:

  ComposeMessage(aCompType, Components.interfaces.nsIMsgCompType.ReplyToSender,
                 Components.interfaces.nsIMsgCompFormat.PlainText,
                 gFolderDisplay ? GetFirstSelectedMsgFolder() : null,
                 gFolderDisplay ? gFolderDisplay.selectedMessageUris : null);

If you really just want "reply in the non-default format", that's much easier:

  MsgReplyMessage({shiftKey: true});

Take a look at the code around here for more function names: http://mxr.mozilla.org/comm-central/source/mail/base/content/mailWindowOverlay.js#1502

Comment 15

[franc]

(In reply to Jim Porter (:squib) from comment #14)
> If you really just want "reply in the non-default format", that's much
> easier:
> 
>   MsgReplyMessage({shiftKey: true});
>

Good heavens! This works! So "easy" :)
Thanks a lot.
I read before, that this is not doable with Keyconfig but never tried. 
Now it works :)

Comment 16

[Jim Porter (:squib)]

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

Sorry, *this* is what you'd want for the first code block:

   ComposeMessage(Components.interfaces.nsIMsgCompType.ReplyToSender,
                  Components.interfaces.nsIMsgCompFormat.PlainText,
                  gFolderDisplay ? GetFirstSelectedMsgFolder() : null,
                  gFolderDisplay ? gFolderDisplay.selectedMessageUris : null);

Comment 17

[franc]

I use this with a global shortcut CTRL+SHIFT+N in the keyconfig Add-On to compose a mail in the opposite way than it is defined in my accounts (all plaintext now):

ComposeMessage(Components.interfaces.nsIMsgCompType.New, Components.interfaces.nsIMsgCompFormat.OppositeOfDefault, gFolderDisplay ? GetFirstSelectedMsgFolder() : null, gFolderDisplay ? gFolderDisplay.selectedMessageUris : null);

But amazingly the next mail I compose (after this mail triggered by this shortcut) will be the opposite style again (in my case, html again). 
Only the third mail is then again normal setting (plain text), not opposite of the compose setting in the account. 
E.g:
(I have set plain text composing in all my accounts)

CTRL+SHIFT+N: opens a new html composing mail window
CTRL+N: opens again a html composing mail window
CTRL+N: opens a plain text window
...
CTRL+N: still plain text

This is weird.