428062 - Command Shift M broken (os x, nightlies)

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[David Ascher (:davida)]

Thunderbird 3.0a1pre ID:2008040803

Expected behavior: Command+Shift+M does the "move to ... again" command as the menus indicate
Actual behavior: Command+Shift+M does the same thing as Command+M (new mail).


Command+Shift+M (move to <folder> again) doesn't work in this latest update.  I wonder if that's due to the changes related to bug 382138 and bug 382138.

Comment 1

[David Ascher (:davida)]

I meant bug 398514 for the second bug.

Comment 2

[Magnus Melin [:mkmelin]]

<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=ThunderbirdTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-04-07+03%3A00%3A00&maxdate=2008-04-08+03%3A00%3A00&cvsroot=%2Fcvsroot>

Phil, will checking in the tb hackaround backout patch in bug 382138 fix this?

Comment 3

[Phil Ringnalda (:philor)]

Nope, that only affects which code path we take to set the enabled state of the Edit menu commands. Somewhere in the tangle of regressions blocking bug 398514 is the patch that will (or won't) fix this, but I was hoping it would land and fix it before I had to chase down which one it is, and see whether or not it does. 

Probably, it's bug 359638.

Comment 4

[Phil Ringnalda (:philor)]

Erm. After applying the patch in bug 359638, cmd+shift+M opens a new message, and cmd+m minimizes the window. That's not quite what I was expecting.

Comment 5

[David Ascher (:davida)]

I'm finding this is a blocker in my personal use of nightlies, so I'll approve at blocking 3a1.  We may have to shift it back if resources & time don't line up.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

It looks like some of those referenced bugs caused a long-standing binding to finally show up.  Namely, on OS X, both "accel N" and "accel,shift M" should trigger the "new message window".  On all other platforms, "accel N" and "accel M" open the "new message window".

Who is the key-binding czar?

--- mail/locales/en-US/chrom/messenger/mailOverlay.dtd:
<!ENTITY  newMessageCmd2.key              "N">
<!ENTITY  newMessageCmd.key               "M">

--- mail/base/content/mailOverlay.xul:
#ifdef XP_MACOSX
  <key id="key_newMessage" key="&newMessageCmd.key;" command="cmd_newMessage" modifiers="accel,shift"/>
  <key id="key_newMessage2" key="&newMessageCmd2.key;" command="cmd_newMessage" modifiers="accel"/>
#else
  <key id="key_newMessage"  key="&newMessageCmd.key;" command="cmd_newMessage" modifiers="accel"/>
  <key id="key_newMessage2" key="&newMessageCmd2.key;" command="cmd_newMessage" modifiers="accel"/>
#endif

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

For investigation purposes, bug 350543 introduced the 'move again' feature and the conflicting binding.  What is confusing is that sspitzer actually mentioned the binding conflict on the bug, but it seems his comment wasn't addressed.

Bug 271315 changed the new message bindings slightly to their current state, and had some discussion about address book.  This left us with our current state, I believe, where "accel N" in the address book is "New... Address Book Card..." and "accel,shift M" is "New... Message".

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Make the mac use cmd-I for move again, using a new entity

As an interim 3a1 solution, add a new entity that likes the letter "i".  Only use this binding on OS X, and only use "accel" (command) for it (no shift).  This leaves all other platforms as they were, using "accel,shift m"; they have no conflict to need a change.

Comment 9

[Phil Ringnalda (:philor)]

Comment on attachment 316726 [details] [diff] [review]
Make the mac use cmd-I for move again, using a new entity

Keys, oh keys, how I hate you.

Cmd+I was the second Mac shortcut I learned when I switched, after the nearly useless Cmd+M and before the useful Cmd+H. What I learned was that it was a safe way to get a properties dialog for something that had one, or to do nothing if it didn't. Having the key combo that gets info for a file in a similar-looking tree in Finder, and gets info for the mail account in the exact same tree in Mail.app, and gets info for the folder in a similar-looking tree in NetNewsWire, and gets info for a file in a similar-looking tree in iTunes, instead make the current message disappear off the face of the earth (bug reports lead me to believe that most users don't think of Undo as something to rely on for anything other than text editing) is not a happy idea.

Since we don't have a spare cmd+one-letter, and we have to do something different on Mac anyway, let's just go with Mail.app compat and use cmd+option+T.

Comment 10

[Phil Ringnalda (:philor)]

Where by "Mail.app compat" I mean "do anything other than what Mail.app does" and by "cmd+option+T" I mean "go back to the drawing board, since we certainly don't want to steal cmd+option+T from Edit - Special Characters"

Comment 11

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Make the modifiers amount to command-option, OS X only.

Now we try command-option-M.  This has the added benefit of not adding a new entity that needs to be 'localized'.  Key choice made by philor.  Long live the key czar!

Comment 12

[Phil Ringnalda (:philor)]

Comment on attachment 316756 [details] [diff] [review]
Make the modifiers amount to command-option, OS X only.

Lovely, r=philringnalda

Comment 13

[Phil Ringnalda (:philor)]

mail/base/content/mailWindowOverlay.xul 1.237