509446 - New tab button in toolbar doesn't have a tooltip

Status: RESOLVED WONTFIX

(Firefox :: Toolbars and Customization, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090810 Shiretoko/3.5.3pre ID:20090810040503

Using the customize toolbar dialog and placing the new tab button onto a toolbar doesn't show the tooltip when hovering over this button. That's a regression against Firefox 3.0. Visible on all platforms.

Comment 1

[Nochum Sossonko [:Natch]]

More fallout from bug 474917, added the string there but I forgot to add the tooltip. This only applies to branch, trunk works fine.

Comment 2

[Nochum Sossonko [:Natch]]

Attachment: fix

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 393669 [details] [diff] [review]
fix

I don't think that this is worth bothering to fix on the branch, really, but whatever.

Comment 4

[Nochum Sossonko [:Natch]]

The reason I think it may be worth it is for screen readers, which I believe use the tooltip text to describe the item on screen. The button has no other text to describe it.

Comment 5

[Nochum Sossonko [:Natch]]

Comment on attachment 393669 [details] [diff] [review]
fix

Drivers, this is a trivial, no-risk change. The string is already on the 1.9.1 branch.

Comment 6

[Marco Zehe (:MarcoZ)]

(In reply to comment #4)
> The reason I think it may be worth it is for screen readers, which I believe
> use the tooltip text to describe the item on screen. The button has no other
> text to describe it.

Correct, right now Screen readers identify it as a nameless button.

Comment 7

[Nochum Sossonko [:Natch]]

Pike: would this change cause any issues for l10n? No strings are being added, only a previously unused string is now being put to use.

Comment 8

[Axel Hecht [:Pike]]

Using unused strings is an l10n-impact change, yes.

It doesn't break building l10n, but it should be manually tested on all localizations, on platforms as required per patch.

Which of the two are you putting to use? Looking at http://mxr.mozilla.org/l10n-mozilla1.9.1/search?string=newTabButton.tooltip&find=browser/chrome, the values for both should probably match, assuming that one is for the tab bar, and one for the toolbar. Checking that might suffice in this case, not sure right now.

Comment 9

[Nochum Sossonko [:Natch]]

It's the entity in browser.dtd. You want me to check-out and build each locale? I'm not going to have time to do that, but from what I've seen on l10n's mxr it seems this entity is covered.

Comment 10

[Nochum Sossonko [:Natch]]

Pike: After looking over the link you provided, the following locales have different translations for browser.dtd vs. tabbrowser.dtd:

ku, bn-BD, si, bn-IN, hi-IN, fr, kn, ta-LK

hi-IN especially has a problem as they don't translate the one in browser.dtd, they use the English version of the string there. Any way to get in touch with these localizers and see what's up?

Comment 11

[Axel Hecht [:Pike]]

I think we should get this bug triaged before we add noise in the l10n community. If we decide to take this bug, there's a bunch of communication, including CCing owners of those locales onto this bug.

TRIAGE NOTE: This bug exposes currently unused strings on 1.9.1, which are not necessarily right at least for the locales mentioned in comment 10.

Comment 12

[Daniel Veditz [:dveditz]]

Comment on attachment 393669 [details] [diff] [review]
fix

minusing for branch without a better l10n story and justification. Am I reading bug 474917 correctly that it only landed on the 1.9.1 branch? If so why was that?

Comment 13

[Nochum Sossonko [:Natch]]

(In reply to comment #12)
> (From update of attachment 393669 [details] [diff] [review])
> minusing for branch without a better l10n story and justification. Am I reading
> bug 474917 correctly that it only landed on the 1.9.1 branch? If so why was
> that?

Bug 456984 came late in the game for 3.5, and it was decided that a non-l10n impacting patch should be split out of the original trunk patch for branch. Then, later, the l10n stuff was to be landed in bug 474917, so it really only concerned branch (3.5).

The only reason this should have a fighting chance on branch is because of the accessibility reason mentioned in comment 4. This bug only concerns the 3.5 branch (trunk works just fine), so this bug is inherently wontfix.

Note: http://mxr.mozilla.org/l10n-mozilla1.9.2/search?string=newTabButton.tooltip&find=browser/chrome (1.9.2) shows nearly the same issues with the problematic locales.