283530 - shifted compose and forward events sometimes lose their shift-attribute

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Dan Mosedale (:dmosedale, :dmose)]

An IRC snippet: 

richard: clicking compose or hitting ctrl-m composes
richard: shift-click-compose brings up the compose in HTML window, but
shift-ctrl-m doesn't
richard: clicking reply does a reply, shift-click reply replies in html but
shift-ctrl-r doesn't do reply-in-html
richard: It's worse for forwarding.  If I'm setup for default compose in text
only, then I can't forward an html mail even by shift-forward (never mind
ctrl-shift-L)
richard: ..it always forwards in textmode so I lose the formatting.  I have to
switch to default-html-compose and then forward and then switch back
richard: I *could* use message->forward->as attachment but then I lose the
ability to edit inline

After discussion with scott & david, patch looks straightforward.  I'll cons one
up soon.

Comment 1

[WADA:World Anti-bad-Duping Agency]

"Forward" has different issue from inconsistency of "Shift+CTRL+L" with
"Shift+Click Forward".
See Bug 254931(Bug 228562 for TB) and Bug 111298, which are incompatible with
each other...

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: fix shifted menu-clicks, v1

This is a multi-part bug.  As a beginning, here's a first cut at a patch that
makes the shift modifier automatically do the opposite thing from the various
"new mail" menu items.	Now this patch as it stands is likely to cause problems
with Mac OSX because of the fix for bug 223871.  I could certainly hack the
patch to "ignore the shift modifier on the mac", but it'd be nice if we could
find a cross-platform way to deal with this.  Any suggestions?

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

Interestingly, on Linux, control-M and control-N both map to "new message". 
Anyone know the history of why that is?  What do command-N and command-shift-N
do on Mac?

Comment 4

[Mike Cowperthwaite]

I disagree that Shift should work with shortcuts; nor should it work when 
selecting an item from a menu.

For the case of the shift+Fwd button, see bug 254931.  (Which is pretty easy to 
find by searching Bugzilla for "shift forward".)

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Mike, would you care to elaborate on why you feel that way?

Comment 6

[Mike Cowperthwaite]

(In reply to comment #5)
> Mike, would you care to elaborate on why you feel that way?

Primarily because the UI model of a shift plus a menu is pretty obscure.  
Shifting is a neat hack that works for toolbuttons, but it's something you need 
to ask about or read help for.  It's not an obvious UI action.

On the menu, it's a little trickier than on a toolbar -- when exactly does the 
Shift need to be held down?  Shift+click is more straightforward than [shift, 
navigate, select], or [navigate, shift+select].  The menu case is a little more 
complex by the fact that menu items can be selected on mouse-up or mouse-down, 
and the added wrinkle of context menus.  Also, there are menus in the toolbar's 
dropdowns -- it turns into a creeping net of requirements for something that 
started out as a hack.

For the shortcut case: Ctrl+Shift+R is already used for Reply All, so you'd have 
to change things around to make it work.  This is part of a general problem of 
limited numbers of shortcuts and a multitude of functions.

However, other than that, I guess I don't really object to using shift on the 
shortcut -- viz current usage of Ctrl-T vs. Ctrl-Shift-T -- but it seems that 
ought to be made consistent.  It would be neat, and consistent, if 
Shift+Get New performed Get All New.  (But that's another bug.)


Note that Scott has said he wants to make the compose window support toggling 
back and forth -- bug 216132 / bug 140800.  If that feature is implemented, 
there would be no need for the obscure UI at all for the toggle default HTML 
mode.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Assigning bugs that I'm not actively working on back to nobody; use
SearchForThis as a search term if you want to delete all related bugmail at
once.

Comment 8

[Thomas D. (:thomas8)]

This bug is not actionable, needs STR, Actual Result, Expected Result.

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Thomas D. (needinfo?me) from comment #8)
> This bug is not actionable, needs STR, Actual Result, Expected Result.

aceman, does the patch make sense / is it still needed?

Comment 10

[:aceman]

Many things in this area have been changed since the report.
I'll leave it to judgement of Thomas if any of the hotkeys described in the original report still do not behave correctly, as he has done the patches and investigations in these 'shifted' compose events.

Comment 11

[Thomas D. (:thomas8)]

(In reply to Dan Mosedale (:dmose, :dmosedale) from comment #0)
> An IRC snippet: 
> 
> richard: clicking compose or hitting ctrl-m composes
> richard: shift-click-compose brings up the compose in HTML window, but
> shift-ctrl-m doesn't
> richard: clicking reply does a reply, shift-click reply replies in html but
> shift-ctrl-r doesn't do reply-in-html

Not a bug, we don't offer Shift+{Start-Message} keyboard shortcuts for opposite format as some of them are already taken (e.g. Ctrl+Shift+R = Reply All, Ctrl+Shift+L = Reply to List).

> richard: It's worse for forwarding.  If I'm setup for default compose in text
> only, then I can't forward an html mail even by shift-forward

wfm.

(In reply to :aceman from comment #10)
> Many things in this area have been changed since the report.
> I'll leave it to judgement of Thomas if any of the hotkeys described in the
> original report still do not behave correctly, as he has done the patches
> and investigations in these 'shifted' compose events.

Thanks. I believe we have fixed them all wrt clicking buttons and menus.
Only Shift+Edit-Button on drafts still seems to fail (but Edit-As-New on plaintext msg will use account format, or opposite if shifted, so users cannot get stuck). Jörg, have we not fixed the "Edit(-Draft)" button yet?

Comment 12

[Jorg K (CEST = GMT+2)]

(In reply to Thomas D. (currently busy elsewhere) from comment #11)
> Jörg, have we not fixed the "Edit(-Draft)" button yet?
To take a shift modifier? That's bug 1392056, right? You've already done the M-C work in bug 1392055.