Closed Bug 997684 Opened 10 years ago Closed 10 years ago

Tooltips in the panel menu shouldn't end with an ellipsis and shouldn't use title capitalization

Categories

(Firefox :: Toolbars and Customization, defect)

29 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 31
Tracking Status
firefox29 --- wontfix
firefox30 --- wontfix
firefox31 --- verified

People

(Reporter: ioana_damy, Assigned: jaws)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [Australis:P5])

Attachments

(2 files, 1 obsolete file)

Reproduced on Firefox 29.0b8 and the latest Firefox 30.0a2 and 31.0a1, on Ubuntu 13.04 32bit and Windows 8.1 64bit.

STR:
1. Launch Firefox with a clean profile.
2. Add all the available buttons to the panel menu. (not neccesary to reproduce this issue, but this way you can see all the tooltips)
Open the panel menu.
3. Hover over the buttons in the panel menu.

Actual Results:
Ellipses seem to be used randomly here. I see no kind of consistency: some tooltips with short text have the ellipsis, others don't.

Expected Results:
Save this page, Find in this page, Open File, Subscribe to this page, Email Link should neither have an ellipsis (especially since there are items like "Open a new Private Browsing window" that are longer and have none).

Note:
It would be nice if the capitalization would be more consistent too (e.g. notice Email Link versus Save this page).
The ellipsis indicates whether the user needs to provide more information to complete an action (such as where to save a file). It's been used that way in menus since at least Windows 3.1, and probably longer. It's not inconsistent in the way you suggest.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
(see also bug 940116 where we actually put a lot of work into making these sensible and correct)
(In reply to :Gijs Kruitbosch from comment #2)
> The ellipsis indicates whether the user needs to provide more information to
> complete an action (such as where to save a file). It's been used that way
> in menus since at least Windows 3.1, and probably longer. It's not
> inconsistent in the way you suggest.

As a user, this doesn't make too much sense to me. People would expect by default that you need to give input when selecting options like opening a file anyway.

(In reply to :Gijs Kruitbosch from comment #3)
> (see also bug 940116 where we actually put a lot of work into making these
> sensible and correct)

Besides this, we should also think of actually being constant for once. As I specify in comment 0, it doesn't look that nice to have "Open File" and "Save this page". It should either be "Open File" and "Save Page" OR "Open a file" and "Save this page".
(In reply to :Gijs Kruitbosch from comment #2)
> The ellipsis indicates whether the user needs to provide more information to
> complete an action (such as where to save a file). It's been used that way
> in menus since at least Windows 3.1, and probably longer. It's not
> inconsistent in the way you suggest.

This is true for labels. Tooltips aren't supposed to have them. Ironically, the labels lack ellipses here.

(In reply to Ioana Budnar, QA [:ioana] from comment #4)
> Besides this, we should also think of actually being constant for once. As I
> specify in comment 0, it doesn't look that nice to have "Open File" and
> "Save this page". It should either be "Open File" and "Save Page" OR "Open a
> file" and "Save this page".

The latter -- tooltips shouldn't use title capitalization.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: The ellipsis is used randomly in the panel menu → Tooltips in the panel menu shouldn't end with an ellipsis and shouldn't use title capitalization
Attached patch Patch (obsolete) — Splinter Review
Assignee: nobody → jaws
Status: REOPENED → ASSIGNED
Attachment #8409525 - Flags: review?(dao)
Whiteboard: [Australis:P5]
Comment on attachment 8409525 [details] [diff] [review]
Patch

> developer-button.label = Developer
> # LOCALIZATION NOTE(developer-button.tooltiptext): %S is the keyboard shortcut
>-developer-button.tooltiptext = Web Developer Tools (%S)
>+developer-button.tooltiptext2 = Web Developer tools (%S)

Web developer tools?
or: Open Web developer tools, since it seems that most tooltips come with a verb?

> add-ons-button.label = Add-ons
>-# LOCALIZATION NOTE(add-ons-button.tooltiptext2): %S is the keyboard shortcut
>-add-ons-button.tooltiptext2 = Open Add-ons Manager (%S)
>+# LOCALIZATION NOTE(add-ons-button.tooltiptext3): %S is the keyboard shortcut
>+add-ons-button.tooltiptext3 = Open the Add-ons Manager (%S)

Manage your add-ons?

> preferences-button.label = Preferences
> preferences-button.tooltiptext2 = Open Preferences
> preferences-button.tooltiptext.withshortcut = Open Preferences (%S)

should be lowercased too unless we consider Preferences a proper name, which I think we shouldn't.

> # LOCALIZATION NOTE (characterencoding-button.label): The \u00ad character at the beginning
> # of the string is used to disable auto hyphenation on the button text when it is displayed
> # in the menu panel.
> characterencoding-button.label = \u00adCharacter Encoding
> characterencoding-button.tooltiptext2 = Show Character Encoding options

should be lowercased too (these are just the ones I saw in the context included in this patch -- please go through the file and see if there are more)
Attachment #8409525 - Flags: review?(dao) → review-
Attached patch Patch v2Splinter Review
I made the changes that you requested. The Edit and Zoom controls have a tooltiptext that is provided, but I couldn't find how they are displayed (the nested toolbarbuttons' tooltiptext is always used).

Removing these tooltiptext properties altogether will cause some CustomizableUI errors since it isn't finding the tooltiptext for the control. This is something that we could look in to handling for a follow-up but also seems like an edge case that isn't likely to happen often.
Attachment #8409525 - Attachment is obsolete: true
Attachment #8410391 - Flags: review?(dao)
Attachment #8410391 - Flags: review?(dao) → review+
Pushed to fx-team: https://hg.mozilla.org/integration/fx-team/rev/505186fee60c

Marking as wontfix for 29 and 30 since it's too late for beta, and wontfix for aurora due to l10n changes.
Whiteboard: [Australis:P5] → [Australis:P5][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/505186fee60c
Status: ASSIGNED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P5][fixed-in-fx-team] → [Australis:P5]
Target Milestone: --- → Firefox 31
I've verified the fix on: Win 7 64bit, Win 8 64bit, Mac OS X 10.8.5 and Ubuntu 13.04 64bit. I used the latest Firefox 31 Beta builds available: Beta 2 for Windows (BuildID: 20140616143923) and Beta 3 for Mac OS and Ubuntu(BuildID: 20140619131915).

Title capitalization is no longer used, and ellipsis no longer display for tooltips, with one exception for "Print":
- on Windows and Linux the tooltip for "Print" reads: "Print this page" (no keyboard shortcut)
- on Mac OS the tooltip for "Print" reads: "Print this page... (<cmd>P)" (with keyboard shortcut) 

Should we not display any keyboard shortcut on Mac (in which case there would probably be no ellipsis), or should we display a shortcut also on Windows and Linux (and thus adjust the tooltip so no ellipsis will show)?
Flags: needinfo?(jaws)
Flags: needinfo?(dao)
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #11)
> Title capitalization is no longer used, and ellipsis no longer display for
> tooltips, with one exception for "Print":
> - on Windows and Linux the tooltip for "Print" reads: "Print this page" (no
> keyboard shortcut)
> - on Mac OS the tooltip for "Print" reads: "Print this page... (<cmd>P)"
> (with keyboard shortcut) 
> 
> Should we not display any keyboard shortcut on Mac (in which case there
> would probably be no ellipsis),

Why would we want to hide the keyboard shortcut on Mac? The ellipsis shouldn't be there either way.

> or should we display a shortcut also on
> Windows and Linux (and thus adjust the tooltip so no ellipsis will show)?

We don't have a shortcut for the print preview on Windows and Linux.
Flags: needinfo?(dao)
(In reply to Dão Gottwald [:dao] from comment #12)
> Why would we want to hide the keyboard shortcut on Mac? The ellipsis
> shouldn't be there either way.

Dão, should I reopen this or do you want me to file a separate issue (ellipsis should not show for Print item in the Panel menu)?
Flags: needinfo?(jaws) → needinfo?(dao)
A new bug seems appropriate.
Flags: needinfo?(dao)
Depends on: 1028230
See Also: 1028230
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.