Last Comment Bug 526998 - Implement F2 keyboard shortcut for renaming focused attachments when composing (on Windows and Unix)
: Implement F2 keyboard shortcut for renaming focused attachments when composin...
Status: RESOLVED FIXED
: access
Product: Thunderbird
Classification: Client Software
Component: Message Compose Window (show other bugs)
: Trunk
: All All
: -- enhancement with 2 votes (vote)
: Thunderbird 12.0
Assigned To: Jim Porter (:squib)
:
Mentors:
Depends on: 929037 718288 799451
Blocks: 690631 tb-keyboard-tracker 718252 670502
  Show dependency treegraph
 
Reported: 2009-11-06 06:33 PST by Thomas D. (currently busy elsewhere; needinfo?me)
Modified: 2013-10-22 06:17 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
request UI-review for F2 for renaming focused attachments in composition (417 bytes, text/plain)
2011-05-01 14:41 PDT, Thomas D. (currently busy elsewhere; needinfo?me)
bwinton: feedback+
Details
Request ui-review for F2 Keyboard shortcut to rename focused attachments when composing (Win + Unix).txt (1.09 KB, text/plain)
2011-10-30 06:36 PDT, Thomas D. (currently busy elsewhere; needinfo?me)
bwinton: ui‑review+
Details
Add keyboard shortcut F2 for renaming attachments (win+unix) (2.34 KB, patch)
2011-11-10 08:15 PST, Thomas D. (currently busy elsewhere; needinfo?me)
squibblyflabbetydoo: review-
Details | Diff | Splinter Review
Clean up the command controllers while we're here (17.17 KB, patch)
2011-11-12 13:24 PST, Jim Porter (:squib)
no flags Details | Diff | Splinter Review
Put Rename Attachment under the Edit menu (4.58 KB, patch)
2011-11-12 17:58 PST, Jim Porter (:squib)
no flags Details | Diff | Splinter Review
The Edit menu now (16.92 KB, image/png)
2011-11-12 18:00 PST, Jim Porter (:squib)
bwinton: ui‑review-
Details
Attach the right patch this time (17.08 KB, patch)
2011-11-13 11:48 PST, Jim Porter (:squib)
no flags Details | Diff | Splinter Review
Use R_e_name Attachment (17.29 KB, patch)
2011-11-15 21:58 PST, Jim Porter (:squib)
standard8: review+
bwinton: ui‑review+
Details | Diff | Splinter Review
Fix test failures and strings (17.73 KB, patch)
2012-01-15 12:15 PST, Jim Porter (:squib)
no flags Details | Diff | Splinter Review
Interdiff between previously-committed and current versions (3.75 KB, patch)
2012-01-15 12:16 PST, Jim Porter (:squib)
no flags Details | Diff | Splinter Review
Fix Mozmill tests (18.35 KB, patch)
2012-01-18 19:06 PST, Jim Porter (:squib)
mconley: review+
Details | Diff | Splinter Review

Description Thomas D. (currently busy elsewhere; needinfo?me) 2009-11-06 06:33:56 PST
In Windows and a lot of Windows programs, F2 will rename the focused object (e.g. rename focused file(s) in Explorer, rename current file in IrfanView, edit cell content in Excel, etc.). At least for windows builds, we should implement the same shortcut for renaming focused attachments in msg composition.

STR

1 compose msg on windows, add attachment
2 [review] focus one attachment (e.g. click on it, will be highlighted with dotted border)
3 press F2 keyboard shortcut to rename the focused attachment

Actual
- nothing

Expected
- enable in-place editing of filename (same behaviour as in Windows Explorer: highlight file name text, show cursor for in-place renaming)
Comment 1 Thomas D. (currently busy elsewhere; needinfo?me) 2011-01-05 05:19:37 PST
For a start, even a partial implementation whereby F2 would trigger the current renaming dialogue (instead of in-place renaming) would be highly helpful for more efficient renaming.
Comment 2 Thomas D. (currently busy elsewhere; needinfo?me) 2011-05-01 14:41:43 PDT
Created attachment 529389 [details]
request UI-review for F2 for renaming focused attachments in composition

This should be straightforward...
Comment 3 Jim Porter (:squib) 2011-05-01 15:19:39 PDT
This should also work on Linux (GNOME, anyway).
Comment 4 Thomas D. (currently busy elsewhere; needinfo?me) 2011-05-02 10:54:18 PDT
Linux-Ubuntu has F2 for renaming files, too.
What about MAC OS?
Comment 5 Ludovic Hirlimann [:Usul] 2011-05-02 10:58:31 PDT
Macs don't use F functions keys they are reserved for system fucntions.
Comment 6 Blake Winton (:bwinton) (:☕️) 2011-05-20 13:00:53 PDT
Comment on attachment 529389 [details]
request UI-review for F2 for renaming focused attachments in composition

For Mac, the Enter or Return key is used.  It seems reasonable to use that in the list of attachments, as it also does nothing.

Since there's no real UI for me to review yet, I'm going to clear the ui-review request and say feedback=me.

Thanks,
Blake.
Comment 7 Jim Porter (:squib) 2011-05-20 13:53:02 PDT
(In reply to comment #6)
> For Mac, the Enter or Return key is used.  It seems reasonable to use that
> in the list of attachments, as it also does nothing.

I think my patch in bug 630759 will make enter open up the file (or, more generally, do whatever double-clicking does). I suppose I could add some Mac-only logic to it though...
Comment 8 Thomas D. (currently busy elsewhere; needinfo?me) 2011-10-13 01:29:37 PDT
Blake, it would be great if we could implement this for Windows and Unix and then perhaps add some Mac-only logic later (after all, we won't be making it any worse for Mac users by improving on other OS), what do you think?

(In reply to Jim Porter (:squib) from comment #7)
> (In reply to comment #6)
> > For Mac, the Enter or Return key is used.  It seems reasonable to use that
> > in the list of attachments, as it also does nothing.
> 
> I think my patch in bug 630759 will make enter open up the file (or, more
> generally, do whatever double-clicking does). I suppose I could add some
> Mac-only logic to it though...

Jim, what does Enter do on the MAC right now? And what's their default keyboard shortcut for opening files (i. e. for the double-click action)?
Could you think of a MAC-only logic for this?
Comment 9 Thomas D. (currently busy elsewhere; needinfo?me) 2011-10-30 06:36:03 PDT
Created attachment 570543 [details]
Request ui-review for F2 Keyboard shortcut to rename focused attachments when composing (Win + Unix).txt

Blake, this already has your feedback+ from comment 6 (-> 2 minutes to ui-review).

To move this bug forward (rather than losing more years) I have clarified some of the details:
- for now, let's just add the F2 keyboard shortcut to the existing UI, triggering the "Rename Attachment" dialogue (instead of more complex in-place-renaming which has same ux-efficiency and use pattern)
- for now, let's not change anything for the MAC (see comment 7 and comment 8)

Attached file describes the requested UI for your UI-review.
Comment 10 Blake Winton (:bwinton) (:☕️) 2011-11-09 08:07:54 PST
Comment on attachment 570543 [details]
Request ui-review for F2 Keyboard shortcut to rename focused attachments when composing (Win + Unix).txt

This sounds reasonable, as long as we file a follow-up bug to get in-place renaming working.

Thanks,
Blake.
Comment 11 Thomas D. (currently busy elsewhere; needinfo?me) 2011-11-10 08:15:47 PST
Created attachment 573521 [details] [diff] [review]
Add keyboard shortcut F2 for renaming attachments (win+unix)

Fix this! This patch implements F2 to rename focused attachment on Windows and Linux, as agreed per comment 10. Works like a charme on my Daily Bird (on Windows): In message composition, select a single attachment, press F2, type new attachment file name, ENTER - done!
Comment 12 Jim Porter (:squib) 2011-11-10 09:06:13 PST
Comment on attachment 573521 [details] [diff] [review]
Add keyboard shortcut F2 for renaming attachments (win+unix)

I'm stealing review on this and saying "no" because I really think we should add a proper command controller for this, especially since the main window controller already tries to handle attachment-related events, but in a really obnoxious way. This would also let us add a menu item for this, which would help to improve discoverability (people would see "Rename...   F2").

I was planning on doing this sooner, but things got pretty hectic with the release/merge. Thomas, if you want to do the command controller version, you're welcome to, but I don't have a problem doing it either.
Comment 13 Jim Porter (:squib) 2011-11-12 13:24:43 PST
Created attachment 574087 [details] [diff] [review]
Clean up the command controllers while we're here

I'm taking a page from bug 690631 and cleaning up the command controllers here so that 1) the code is clearer, 2) the attachment bucket commands are handled more simply, and 3) it'll be easier for add-on authors to add new commands if they like. One reason this is good is that doing this automatically fixes bug 670502.

As a note, I didn't bother trying to use the prevailing brace style in MsgComposeCommands.js, since it's really all over the place. I could change to Allman braces though, if you think that's better.
Comment 14 Jim Porter (:squib) 2011-11-12 13:26:44 PST
Comment on attachment 574087 [details] [diff] [review]
Clean up the command controllers while we're here

Also asking for UI review, since I added "Rename Attachment..." to the File menu. This way, the F2 command will be documented in the program somewhere. Maybe it should go in the Edit menu though?
Comment 15 Thomas D. (currently busy elsewhere; needinfo?me) 2011-11-12 14:11:15 PST
(In reply to Jim Porter (:squib) from comment #14)
> Comment on attachment 574087 [details] [diff] [review] [diff] [details] [review]
> Clean up the command controllers while we're here

Thank you!

> Also asking for UI review, since I added "Rename Attachment..." to the File
> menu. This way, the F2 command will be documented in the program somewhere.
> Maybe it should go in the Edit menu though?

I think EDIT menu is the better choice:
- All other commands on FILE Menu are /message-related/ (i.e. they relate to the message /as a whole/, not to a specific part of it), so "Rename Attachment..." would *not* fit in well
- with focused attachment(s), we already have two attachment-related commands on the EDIT menu: Select All and Remove Attachment. Remove and Rename attachment should be together. In fact, it would be cool if we could add a conditional separator for that situation (only for focus on attachment(s)): 

EDIT
---------------
...
---------------
Cut
Copy
Paste
...
Rewrap
*---------------* (conditional separator when attachments are focused)
Rename attachment...
Remove attachment
----------------
Select all
----------------
Comment 16 Thomas D. (currently busy elsewhere; needinfo?me) 2011-11-12 14:22:08 PST
(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #10)
> Comment on attachment 570543 [details]
> This sounds reasonable, as long as we file a follow-up bug to get in-place
> renaming working.

btw, in-place renaming will not be very easy to handle nor use (ui-wise) for truncated attachment file names (when the attachment bucket box width is less than needed for full attachment file name length). The current dialogue requires exactly the same keystrokes as in-place renaming, so efficiency is the same. Only the single-click-to rename (on an already focused list item caption) is something we can hardly do with the dialogue.
Comment 17 Jim Porter (:squib) 2011-11-12 17:58:44 PST
Created attachment 574104 [details] [diff] [review]
Put Rename Attachment under the Edit menu
Comment 18 Jim Porter (:squib) 2011-11-12 18:00:11 PST
Created attachment 574105 [details]
The Edit menu now

Here's the edit menu with the latest patch, for easier UI review. Note that I moved the "Rewrap" item, since I don't think it really fit where it was to begin with.
Comment 19 Thomas D. (currently busy elsewhere; needinfo?me) 2011-11-13 04:48:11 PST
Comment on attachment 574105 [details]
The Edit menu now

(In reply to Jim Porter (:squib) from comment #18)
> Created attachment 574105 [details]
> The Edit menu now
> Note that I moved the "Rewrap" item, since I don't think it really fit where
> it was to begin with.

? A bit of explanation would be helpful.
Assuming that we still replace the "Delete" menu item with the "Remove Attachment" menu item when attachment(s) are focussed, this will result in the following unfortunate menu sequence (where attachment-related commands are indicated with an asterix (*), and almost all other commands are disabled):

...
Paste as Quotation
Remove Attachment*
Rewrap
Rename Attachment*
-----
Select all*
-----
...

I think it would be helpful to keep attachment-related commands together, so having a disabled "Rewrap" between "Remove Attachment" and "Rename Attachment" is a bit confusing.

Plus, I think the old (current) order and position of "Rewrap" makes sense:
...
Paste (in various flavors)
Rewrap
Delete
...
Right after "Paste" (in different flavors), it might be necessary to "Rewrap". All commands above "Delete" are usually non-destructive. "Delete" should always be the last command (as is good practice in other (context) menus).

So I'd suggest to keep "Rewrap" in its current position.
Furthermore, I'd still think the conditional separator when attachment(s) are focussed, as proposed in my comment 15, would be helpful, because it separates (disabled) message text editing commands from (enabled) attachment-related commands.
Comment 20 Jim Porter (:squib) 2011-11-13 11:41:29 PST
I'm not going to conditionally change the contents of the menu since 1) that's confusing, and 2) it's a lot more work. The delete item should stay in the same spot, no matter what it is that you're deleting. I think it's a bad idea to mess around with the established order of a set of menu items used in pretty much every application out there.

My goal here is to minimize the amount of thinking required when someone skims over this menu: if you want to cut/copy/paste/delete something, you should know where that item is; if you want something else, it should be listed after those items. (A part of me is tempted to move Paste Without Formatting and Paste As Quotation to another section too.)

In any case, the fact that cut/copy/paste are disabled for attachments is only a temporary matter, and one that I intend to fix (though not especially soon, since it'll probably require backend changes).
Comment 21 Jim Porter (:squib) 2011-11-13 11:48:21 PST
Created attachment 574169 [details] [diff] [review]
Attach the right patch this time

Oops, I attached the wrong patch earlier.
Comment 22 Blake Winton (:bwinton) (:☕️) 2011-11-15 12:21:31 PST
Comment on attachment 574105 [details]
The Edit menu now

"_R_edo" and 
"_R_ename Attachment..."

I guess we also have "Paste without Formatti_n_g", and "Prefere_n_ces", but I don't see why we shouldn't fix this while we're here.  ;)

Thanks,
Blake.
Comment 23 Jim Porter (:squib) 2011-11-15 21:57:12 PST
(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #22)
> Comment on attachment 574105 [details]
> The Edit menu now
> 
> "_R_edo" and 
> "_R_ename Attachment..."

How about "R_e_name Attachment..."?

> I guess we also have "Paste without Formatti_n_g", and "Prefere_n_ces", but
> I don't see why we shouldn't fix this while we're here.  ;)

This is a tough one, since "Paste without formatting" is overlaid by editor, so it's hard(er) to change the accesskey, but "Preferences" also appears in the 3pane with "n" as the accesskey, so we should try to be consistent. Is it ok it we just file a new bug on that to decide and just fix the Rename Attachment accesskey here?
Comment 24 Jim Porter (:squib) 2011-11-15 21:58:47 PST
Created attachment 574793 [details] [diff] [review]
Use R_e_name Attachment
Comment 25 Blake Winton (:bwinton) (:☕️) 2011-11-30 09:23:59 PST
Comment on attachment 574793 [details] [diff] [review]
Use R_e_name Attachment

Review of attachment 574793 [details] [diff] [review]:
-----------------------------------------------------------------

> Is it ok it we just file a new bug on that to decide and just fix the Rename Attachment accesskey here?

Yeah, sure.  And the UI changes look good to me, too.
Comment 26 Thomas D. (currently busy elsewhere; needinfo?me) 2011-12-08 04:41:46 PST
Mark, 2yrs after this fine idea was filed, this is now waiting for your review+ to land... would you be able to spare the time before the next release on Dec 20th?

Jim: nitfix ID capitalization: looking at key_renameAttachment and menu_selectAll, I suppose we should have menu_*r*enameAttachment to be consistent (not menu_RenameAttachment).

Otherwise, I'm not sure about the benefit of UI changes in the Edit menu sequence, but it's much more important to see this land, so I'll refrain from further discussion of that minor detail for the time being.
Comment 27 Thomas D. (currently busy elsewhere; needinfo?me) 2011-12-18 09:47:24 PST
Mark Banner (review?), ping? This patch is pretty straightforward, it would be a pity if we miss the deadline on Tuesday 20th Dec...

Blake, anybody else (perhaps you?) with 20 mins to review this?
Comment 28 Thomas D. (currently busy elsewhere; needinfo?me) 2012-01-09 04:07:55 PST
Mark Banner, sorry for not setting the right flag (Assigned), maybe that's what made this hard to track for your review? (review?mbanner pending since 2011-11-15, and the next merge only 22 days away...)
Comment 29 Mark Banner (:standard8) 2012-01-13 05:54:34 PST
Comment on attachment 574793 [details] [diff] [review]
Use R_e_name Attachment

Sorry for the delay, r=Standard8.
Comment 30 Thomas D. (currently busy elsewhere; needinfo?me) 2012-01-13 06:02:14 PST
This is now ready for check-in. Anybody?
Comment 31 Mark Banner (:standard8) 2012-01-13 06:08:46 PST
Just be patient and let Jim land it when he's ready.
Comment 32 Thomas D. (currently busy elsewhere; needinfo?me) 2012-01-13 08:43:12 PST
(In reply to Mark Banner (:standard8) from comment #31)
> Just be patient and let Jim land it when he's ready.

Sorry, I guess I didn't read and apply the small print of "checkin-needed" carefully enough:
> "Keyword to use to get a patch checked in, if you can't check it in yourself."
Which holds true for me (reporter), but it doesn't apply to Jim (patch provider).

Otherwise, I confess I'm keen to not let this miss another release, which would certainly put my patience to the test.
Comment 33 Jim Porter (:squib) 2012-01-14 18:14:01 PST
Checked in: http://hg.mozilla.org/comm-central/rev/25f87dd2453f
Comment 34 Thomas D. (currently busy elsewhere; needinfo?me) 2012-01-15 02:49:50 PST
Jim & Mark: Thank you!!! :)
Comment 35 Jim Porter (:squib) 2012-01-15 11:49:36 PST
Backed out due to test bustage: http://hg.mozilla.org/comm-central/rev/74aaf5c6fa48
Comment 36 Jim Porter (:squib) 2012-01-15 12:15:46 PST
Created attachment 588761 [details] [diff] [review]
Fix test failures and strings

This fixes the test failures (thanks to mconley for writing such thorough tests!) and the string issue reported in bug 718288. Mconley, since you're the one who made the test, I'm asking you for review. Interdiff coming shortly to make things easier.
Comment 37 Jim Porter (:squib) 2012-01-15 12:16:29 PST
Created attachment 588763 [details] [diff] [review]
Interdiff between previously-committed and current versions

Here are the change since this was committed.
Comment 38 Mike Conley (:mconley) - (needinfo me!) 2012-01-17 12:54:31 PST
Hey Jim,

So I tried this patch out, and it mostly works - however, it re-opens that test-attachment.js problem we had a little while back (bug 715488).

Crude steps to reproduce on Linux:

1.  Run the test-attachment.js Mozmill tests
2.  Repeatedly click off of the TB window onto something else, like a terminal window. Do whatever it takes to keep the Thunderbird window from being in focus.

What happens?

A test fails, reporting:

SUMMARY-UNEXPECTED-FAIL | test-attachment.js | test-attachment.js::test_attachments_compose_menu
  EXCEPTION: attachmentBucket is not focused!: 'Delete' != 'Remove Attachments'.
    at: test-folder-display-helpers.js line 2842
       assert_true(false,"attachmentBucket is not focused!: 'Delete' != 'Remove Attachments'.") test-folder-display-helpers.js 2842
       assert_equals("Delete","Remove Attachments","attachmentBucket is not focused!") test-folder-display-helpers.js 2829
       test_attachments_compose_menu() test-attachment.js 463
            frame.js 557
            frame.js 626
            frame.js 669
            frame.js 506
            frame.js 681
            server.js 179
            server.js 183


So, from my investigations into bug 715488, what I think is happening is that the focus event is not being properly dispatched, since the main window is not in focus.  The exact reason for this isn't 100% clear to me, but I think it's a toolkit issue.

My workaround before was with that quick-n-dirty force_focus function that manually called isCommandEnabled on the affected systems (Linux, and potentially OSX). That no longer works, because now we have to manually selected between the two controllers.

Any ideas on how to resolve this?  One way would be to have two functions - force_focus_bucket, and force_focus_non_bucket, each one calling the appropriate controller.  It's crude, but it sidesteps the focus issue.
Comment 39 Jim Porter (:squib) 2012-01-18 19:06:53 PST
Created attachment 589754 [details] [diff] [review]
Fix Mozmill tests

This should fix the Mozmill tests. It's unfortunate that we have to go through this amount of effort to make commands work right under Mozmill, but them's the breaks.
Comment 40 Mike Conley (:mconley) - (needinfo me!) 2012-01-19 06:44:29 PST
Comment on attachment 589754 [details] [diff] [review]
Fix Mozmill tests

Review of attachment 589754 [details] [diff] [review]:
-----------------------------------------------------------------

Jim:

This looks great to me.  The patch does what it advertises, and the tests all pass - even if I force the window not to be focused.

So r=me.  Thanks for your work!

-Mike

::: mail/components/compose/content/MsgComposeCommands.js
@@ +421,4 @@
>      }
>  };
>  
> +var defaultController = {

Don't we prefer let over var now?

@@ +608,5 @@
> +
> +  onEvent: function(event) {},
> +};
> +
> +var attachmentBucketController = {

Same as above, re let vs var.

Also, I like the pattern you've developed for these controllers. Far better than the switch statements.

::: mail/components/compose/content/messengercompose.xul
@@ +157,4 @@
>    <command id="cmd_paste" oncommand="goDoCommand('cmd_paste')" disabled="true"/>
>    <command id="cmd_rewrap" oncommand="goDoCommand('cmd_rewrap')"/>
>    <command id="cmd_delete" oncommand="goDoCommand('cmd_delete')" valueDefault="&deleteCmd.label;" valueDefaultAccessKey="&deleteCmd.accesskey;" valueRemoveAttachmentAccessKey="&removeAttachment.accesskey;" disabled="true"/>
> +  <command id="cmd_selectAll" oncommand="goDoCommand('cmd_selectAll')" disabled="true"/>

Just curious - why were these moved?

::: mail/test/mozmill/attachment/test-attachment.js
@@ -449,1 +450,5 @@
> >        cwc.window.defaultController.isCommandEnabled("cmd_delete");
> > +
> > +      // Walk up the DOM tree and call isCommandEnabled on the first controller
> > +      // that supports "cmd_delete".
> > +      while (element != cwc.window.document) {

*sigh*, yes, this is very unfortunate.  :(

But it does make the tests pass for me.
Comment 41 Jim Porter (:squib) 2012-01-19 16:11:15 PST
(In reply to Mike Conley (:mconley) from comment #40)
> > +var defaultController = {
> 
> Don't we prefer let over var now?

My understanding was that we use "var" for globals, and "let" for locals, though I expect it doesn't actually matter when you're in global scope. Nevertheless, when I see "var" these days, I think "global" in my head...

> Also, I like the pattern you've developed for these controllers. Far better
> than the switch statements.

There's a whole bug on this at bug 690631. I'd like to use this style universally, since it prevents a lot of errors and helps improve code-locality (now isEnabled and doCommand are next to each other for each command).

> ::: mail/components/compose/content/messengercompose.xul
> @@ +157,4 @@
> >    <command id="cmd_paste" oncommand="goDoCommand('cmd_paste')" disabled="true"/>
> >    <command id="cmd_rewrap" oncommand="goDoCommand('cmd_rewrap')"/>
> >    <command id="cmd_delete" oncommand="goDoCommand('cmd_delete')" valueDefault="&deleteCmd.label;" valueDefaultAccessKey="&deleteCmd.accesskey;" valueRemoveAttachmentAccessKey="&removeAttachment.accesskey;" disabled="true"/>
> > +  <command id="cmd_selectAll" oncommand="goDoCommand('cmd_selectAll')" disabled="true"/>
> 
> Just curious - why were these moved?

I wanted to put them in the order they were in the menus, to minimize confusion.

Anyway, checked in: http://hg.mozilla.org/comm-central/rev/e7388ff07ff9
Comment 42 Thomas D. (currently busy elsewhere; needinfo?me) 2012-01-27 13:16:10 PST
Jen, would you please relnote this for tb12.

I've created an entry in "Keyboard Shortcuts" (1), major revision 5658 (2), but unfortunately, future versions tbx will *always* show in spite of restriction {for tbx} (i.e., they show prematurely and the version restriction "for tbx and above" is ignored, which is a bug, I think),  so I had to comment it out for the time being:

|Attach File||{for tb10}{for win,linux}{key Ctrl+Shift+A}{/for}{for mac}{key Command+Shift+A}{/for}{/for}
|-
<!--|Rename Attachment||{for tb12}{for win,linux}{key F2}{/for}{/for}
|-
-->

(1) https://support.mozillamessaging.com/en-US/kb/keyboard-shortcuts
(2) https://support.mozillamessaging.com/en-US/kb/keyboard-shortcuts/revision/5658
Comment 43 Mark Banner (:standard8) 2012-01-28 03:33:06 PST
This isn't a major feature, nor is it changing anything, so I don't think we need to add it to the actual release notes (which is what relnote is used for), just to the support documentation.

Note You need to log in before you can comment on or make changes to this bug.