[Ubuntu] Dock/Taskbar - The Firefox label is displayed in some strange characters for arabic locale
Categories
(Release Engineering :: Release Automation: L10N, defect)
Tracking
(firefox-esr68 affected, firefox65 wontfix, firefox66 wontfix, firefox67 wontfix, firefox68 wontfix)
People
(Reporter: asoncutean, Unassigned)
Details
(Keywords: regression)
Attachments
(1 file)
113.38 KB,
image/png
|
Details |
[Affected versions]:
- Beta/Release builds
[Affected platforms]:
- Ubuntu 18.04 x64
[Steps to reproduce]:
- Download any beta or release build - ar locale
- Open the browser
- Hover the Firefox icon inside the dock; observe the taskbar
[Expected result]:
- Firefox Web Browser is displayed.
[Actual result]:
- Dubious characters are shown as label (see the attached screenshot)
[Regression range]:
- Not applicable here.
[Additional Notes]:
- I didn’t see this issue on other locale (he, ja, zh-CN, te).
- Nightly label is properly displayed.
- No other platforms/versions are affected, I’ve tested this issue on two Ubuntu 18.04 machines.
Comment 1•5 years ago
|
||
That dock tooltip and tray title-text is rendered by gnome-shell, not by Gecko. So, this isn't a Gecko text/fonts bug.
I don't know where those characters come from, but this is probably a bug in the locale itself, or in our Ubuntu integration, or perhaps it's just that your Ubuntu installation doesn't have a font that can render Arabic...
Moving to Widget:GTK for now (in the direction of "linux integration"), but that's still possibly not the right component.
Comment 2•5 years ago
•
|
||
Hmm, OK, I'm able to get arabic text to show up in the top-tray application-title area, in another application (gedit), by editing this file:
/usr/share/applications/org.gnome.gedit.desktop
...and pasting in e.g. موزيلا فَيَرفُكس
for the Name=...
field there. Then, the next time I start gedit, that arabic text does successfully show up.
I don't know where the localized-build-of-Firefox's equivalent of that .desktop file lives, but my guess is that we're producing some junk (perhaps by encoding the characters incorrectly) when generating that file or metadata or whatever.
Reclassifying to Core|Localization.
Comment 3•5 years ago
|
||
I don't know where that data is coming from, either. Let's move this to automation for now.
Anca, can you detail on exactly which builds you tested? ftp links or the like?
Reporter | ||
Comment 4•5 years ago
|
||
So apparently this is a regression after all. Note that this is not reproducible when using any Nightly build version. Last good official Beta build was 57.0b14, first bad one 58.0b3. I restrain the regression range only to the following: https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=8c3926699de4b2f03f13a93d3750deb445b64396&tochange=cd8409437a4e9a4d34eb1385225c6e33a569642c
Reporter | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 5•5 years ago
|
||
Anca, can you detail on exactly which builds you tested? ftp links or the like?
I can reproduce on 64-bit Ubuntu 19.04, using these builds:
https://ftp.mozilla.org/pub/firefox/releases/58.0b3/linux-x86_64/ar/firefox-58.0b3.tar.bz2
https://ftp.mozilla.org/pub/firefox/releases/67.0b9/linux-x86_64/ar/firefox-67.0b9.tar.bz2
I verified that the "Last good official Beta build" that Anca mentioned (57.0b14) is "good" for me, too:
https://ftp.mozilla.org/pub/firefox/releases/57.0b14/linux-x86_64/ar/firefox-57.0b14.tar.bz2
...though to be clear, that version doesn't attempt to use any arabic characters in the taskbar. The app title is simply shown as "Firefox Web Browser".
Comment 6•5 years ago
|
||
I suspect the regression pushlog from comment 4 won't be of much use, because
(a) it spans an entire release (6 weeks) worth of mozilla-central activity (which isn't explicitly displayed but is probably buried in one of the merge commits)
(b) it seems quite possible that the issue is really from a change in the locale rather than a change in Firefox. Notably, I can't reproduce the bug in the Thai (th) or Hebrew (he) or Chinese (zh-cn) localizations of Firefox, and I would think one of those would trigger the bug if this were a platform-level regression.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 7•4 years ago
|
||
Hi,
I want to point out that this also happens on 68.4.0esr and esr-68.4.1-build1.
Regards, Flor.
Updated•11 months ago
|
Description
•