Closed Bug 449383 Opened 15 years ago Closed 13 years ago

"New Tag..." command should be at top of the message tags list (to go well with long list)

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: xem021-misc, Unassigned)

References

Details

(Whiteboard: fixed by bug 525987)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: DE Thunderbird Version 2.0.0.16 (20080708) 

It takes long scrolling down when adding a "New Tag..." to my very long list of tags. Moving the "New Tag..." command to the top of the message tags list would enhance this great feature and would save me a lot of time.



Reproducible: Always

Steps to Reproduce:
1. right-mouse-click on mail subject within Mail window

Actual Results:  
"New Tag..." command is at the bottom of the message tags list

Expected Results:  
"New Tag..." command is at the top of the message tags list
Thanks for the suggestion. But I don't think so, especially because this is quickly accessible with "N".
=> WONTFIX?
Component: General → Mail Window Front End
QA Contact: general → front-end
I think it would make a lot of sense to move the new tag command up to the top of the list. If we have a list of size (N) we can't reliably place actions we hope to be visible on the bottom of the list.  We could place new tag just below the remove tags command.

This shouldn't be a difficult patch for anybody to make.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm not into patches (at all), but would this be the right place to look at?

http://mxr.mozilla.org/comm-central/source/mail/base/content/mailWindowOverlay.xul#1354

[Indenting & line breaks removed for this comment only]

><menuitem id="addNewTag" label="&addNewTag.label;" accesskey=
>"&addNewTag.accesskey;" oncommand="AddTag();"/>

If yes, all it takes to patch this bug is to move that line 1354 up a little, so that it becomes line 1351. Done.

<menuitem id="addNewTag" label="&addNewTag.label;" accesskey="&addNewTag.accesskey;" oncommand="AddTag();"/>
<menuitem id="tagMenu-tagRemoveAll" oncommand="RemoveAllMessageTags();"/>
<menuseparator id="tagMenuAfterRemoveSeparator"/>

This will place the "New Tag..." just above the "0 Remove All Tags command" so that the numbered commands stay together. "New Tag..." at the top of the menu seems just right (just as "New..." at the top of File Menu). "New Tag..." will be more frequently used than "Remove all Tags", so should be at the top.

  &New Tag...
0 Remove All Tags
-------------------
1 Important
2 Job
... 

Can someone please have mercy and move that single line. Unfortunately I can't get an online diff for a file from my own machine and I don't have any of that hg mercurial stuff installed.
Whiteboard: good first bug - move one line to fix
OS: Windows XP → All
Hardware: x86 → All
Blocks: 525987
I included a patch for this bug in my Patch2 at bug 525987 (attachment 430938 [details] [diff] [review]). There's also a screenshot with that patch applied in attachment 430940 [details].
Just a few lines of code, but kind of tricky to tweak them so the tag menu can create itself without involving the final separator which was made redundant by this fix.
Whiteboard: good first bug - move one line to fix → has patch in bug 525987 (attachment 430938)
Summary: New Tag command should be at top of the message tags list → "New Tag..." command should be at top of the message tags list (to allow long list)
Version: unspecified → Trunk
Summary: "New Tag..." command should be at top of the message tags list (to allow long list) → "New Tag..." command should be at top of the message tags list (to go well with long list)
Blocks: 525890
No longer blocks: 525890
This was explicitly fixed by my patch for bug 525987.

http://hg.mozilla.org/comm-central/rev/b60327000654
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: has patch in bug 525987 (attachment 430938) → fixed by bug 525987
You need to log in before you can comment on or make changes to this bug.