410930 - "Download-Save or Open" Dialog do not show App name with localized name [OS X]

Status: NEW

(Firefox :: File Handling, defect)

Description

[Nicolas Mandil (:NicolasWeb)]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; fr; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; fr; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2

With the first option/radio button "open with" the names showed in the list-control are the english names.

This happens with apple app, should be checked for others

Reproducible: Always

Steps to Reproduce:
1.Try to download a file not natively supported by Fx by clicking on a link
2.
3.
Actual Results:  
English name

Expected Results:  
Official localized names for all app,
 - Apple official localized names (ex: "Preview" should be in FR "Aperçu")
 - other "vendors" official localized names

Comment 1

[Nicolas Mandil (:NicolasWeb)]

Attachment: Actual Dialog

Comment 2

[Florian Quèze [:florian]]

Attachment: Applications prefpane screenshot

This bug is visible in the Applications prefpane too.

The attached screenshot comes from a french nightly on my french macbook.
In the application picker the application name is localized and once you have selected the "Apercu" application, it appears in the Applications prefpane as "Preview".

Comment 3

[Florian Quèze [:florian]]

Nominating for blocking1.9 as this looks really bad.

Comment 4

[Mike Schroepfer]

Is this a regression?

Comment 5

[Nicolas Mandil (:NicolasWeb)]

That's a regression from Fx 1 or Fx 1.5 (I remember this has worked)

Comment 6

[Damon Sicore (:damons)]

Is this something we could take in a dot release, right after final?

Comment 7

[Honza Bambas (:mayhemer)]

If this is a priority, I can take a look. In that case, I would like to ask for few hints:
- what piece of code handles the labels (what is suspected)
- how to test this in trunk build where localizations are missing

Comment 8

[Stan Shebs]

This is not a regression from Fx 2, I just tried the French version of 2.0.0.12 and the same problem appears there. We collect the name of the app from the OS, presumably we're skipping a step where we go from the internal name to its localized name, using the System Preferences setting. I'm inclined to say dot release, given that it's been this way for awhile. To answer Honza's second question, this should be debuggable in a trunk build, because external app names are not affected by browser localization.

Comment 9

[Damon Sicore (:damons)]

-'ing based on Comment #8.  wanted1.9.0.x+.

Thanks, Stan.

Comment 10

[Nicolas Mandil (:NicolasWeb)]

Maybe should block bug 565517 too

Comment 11

[Nicolas Mandil (:NicolasWeb)]

Can someone confirm this on intel too ?

Comment 12

[Alex Limi (:limi) — Firefox UX Team]

Please don't add random issues to the papercut metabugs, that's not why they exist. The paper cut set of bugs is supposed to be a manageable, prioritized list, not a way to get your pet peeve bug fixed.

Comment 13

[Nicolas Mandil (:NicolasWeb)]

Sorry Limi, Have I missunderstood paper cut and polish ? :-S
(I'm learning bugzilla and try to help the most I can, but sometimes I make
mistakes... :-S)

For this one, I don't understand why it's not a pepercut one as it is a small thing to fix and really anoying ? Can you teach me, so I won't make the same mistake again please ?

Comment 14

[Nicolas Mandil (:NicolasWeb)]

This bug still exists with Fx 35 and OSX 10.10.1

is there something to do to help this being fixed ? (ping someone ?)

Comment 15

[Florian Quèze [:florian]]

André, Steven, who would be the right person to move this forward (possibly someone to volunteer to mentor if this can be marked as a good first bug)?

Comment 16

[André Reinald]

If application's plist is set up correctly, this should return the localized Application name as a NSString:

NSString *localizedAppName = [[NSBundle mainBundle] localizedStringForKey:CFBundleDisplayName value:nil table:nil];
if (localizedAppName == nil) {
  localizedAppName = *currentName*;
}

If it returns nil, we can use the currently obtained name. And file a bug to fix the plist.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

The dialog where the "wrong" (non-localized) application name appears is a native dialog -- one over which we have no direct control.  So this bug will be difficult to fix, and maybe impossible.  Furthermore, it will probably require somebody who has at least some skills at reverse-engineering the OS.

I'm not going to have time for this anytime soon.  And quite frankly I don't consider this bug particularly urgent -- so it's difficult to suggest other people on which responsibility for this can be foisted :-)

If I were going to work on this (and like I said, I'm almost certainly *not*), I'd start by comparing Firefox's behavior with that of other localized apps.  If even Safari has this behavior, then it's straightforwardly an Apple bug and needs to be reported to them.  If Chrome doesn't have this bug, then someone should look at Chromium code to see how they invoke this native dialog (if they do), and see how we might be able to change own own behavior.

It may turn out that the crucial factor isn't how we invoke the dialog, but something about how our app bundle is set up.  For example bug 1089363 turned up a case where using zh_TW.lproj instead of zh.proj worked around a similar problem on Yosemite.

Comment 18

[André Reinald]

After some thought, I realize this is a normal Mac app behavior (display localized app name) that we want, and it's probably taken care of by the OS if the plist is filled correctly, which may not be the case. Not sure but this is a good first check to make.

Comment 19

[Florian Quèze [:florian]]

(In reply to Steven Michaud from comment #17)
> The dialog where the "wrong" (non-localized) application name appears is a
> native dialog

Looks like there was a slight misunderstanding here. The native dialogs are correctly localized. It's the application names displayed inside the Firefox UI that aren't localized.

The front-end code uses nsILocalFileMac.bundleDisplayName to get that name.

This getter is implemented at http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#2629 and given what it's doing (string manipulation on the file name), I'm not surprised it's not returning a localized name.

Is there an easy way to adapt the code suggested by André in comment 16 so that it could fit in this method?

Comment 20

[Steven Michaud [:smichaud] (Retired)]

Oops, sorry.  Yes I did misunderstand, and the dialog this bug is concerned with is a Firefox dialog (not a native one).  In fact you can display that dialog by clicking on attachment 295513 [details].  Sorry for the confusion :-(

But I'm still horribly busy, and won't have time for this bug anytime soon.  Even just digging in enough to understand what's going wrong will take more time than I currently have.

Remind me again in a couple of weeks.  Things may be better then.

Comment 21

[Florian Quèze [:florian]]

André told me there may be relevant information on this documentation page: https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFBundleRef/index.html

Hopefully this will help if someone wants to start hacking on this :-).