Open Bug 1537704 Opened 6 years ago Updated 2 years ago

Links like "Learn more" in Preferences lead to an error page not found

Categories

(Core :: Internationalization, defect, P3)

Product:
Core
Component:
Internationalization
Version:
68 Branch
Type:
defect

Tracking

()

People

(Reporter: anthony.bocci, Unassigned)

References

Details

Attachments

(1 file)

firefox-nightly-config.png
103.31 KB, image/png
Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

I went in the preferences by typing "about:preferences" in the address bar.
I scrolled untill reach the part about DRM content.
I clicked on "Learn more" aside of the "Play DRM-controlled content." (It happens with several links)

Actual results:

A new tab has been opened, and the page was an error 404, page not found.

Expected results:

A new tab should have been opened and I should saw the right documentation page.

Component: Untriaged → Preferences

Which date is your nightly (you can check in Help > About Firefox Nightly)? What is the 404 page's URL?

(The link wfm on mac, so either this is a Linux problem or a problem specific to a newer/older nightly than what I'm testing on)

Flags: needinfo?(boccianthony)

My Nightly is 68.0a1 (2019-03-18) (64-bit).

The link (I continue with the example of the DRM-related link) is https://support.mozilla.org/1/firefox/68.0a1/Linux/und/drm-content. It's then redirected to https://support.mozilla.org/fr/und/kb/enable-drm?as=u&utm_source=inproduct.

Flags: needinfo?(boccianthony)

(In reply to Anthony B from comment #2)

My Nightly is 68.0a1 (2019-03-18) (64-bit).

The link (I continue with the example of the DRM-related link) is https://support.mozilla.org/1/firefox/68.0a1/Linux/und/drm-content. It's then redirected to https://support.mozilla.org/fr/und/kb/enable-drm?as=u&utm_source=inproduct.

Thanks for the quick response. Hm, apparently we think your locale is "und", whatever that is. Can you copy the "Internationalisation & Localisation" section from about:support, please? Also, can you confirm that in about:config, if you search for "app.support.baseURL", it's set to "https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/" ?

Francesco, who knows about SUMO and can perhaps fix things on their end so that if we pass this type of locale we load something better than a 404 (perhaps using accept-language or similar) ? Also, who knows how the i18n bits slot into the formatURLPref() stuff (ie what gets put in for %LOCALE% ) ?

Flags: needinfo?(francesco.lodolo)
Flags: needinfo?(boccianthony)

You're welcome. Here is the asked section from about:support.

Application Settings
Requested Locales ["fr-FR"]
Available Locales ["en-US"]
App Locales ["und","en-US"]
Regional Preferences ["und","en-US"]
Default Locale "und"
Operating System
System Locales ["fr-FR"]
Regional Preferences ["fr-FR"]

Also, here is the information from about:config: https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/. It seams equal to yours.

I've not set the default locale in my browser (or I don't remember). Is it set from the OS?

Flags: needinfo?(boccianthony)

(In reply to Anthony B from comment #4)

You're welcome. Here is the asked section from about:support.

Application Settings
Requested Locales ["fr-FR"]
Available Locales ["en-US"]
App Locales ["und","en-US"]
Regional Preferences ["und","en-US"]
Default Locale "und"
Operating System
System Locales ["fr-FR"]
Regional Preferences ["fr-FR"]

Also, here is the information from about:config: https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/. It seams equal to yours.

I've not set the default locale in my browser (or I don't remember). Is it set from the OS?

I don't know, but the "und" value definitely seems like a bug, but it's not in code I know so hopefully other people will help debug / triage this further.

Component: Preferences → Internationalization
Product: Firefox → Core

I guess "und" means "undefined", a kind of default value. But I don't understand why there is no default case (either in Firefox or on the Mozilla website) to see the page.

Anyways I'm available if you need more informations.

In about:config, do you have a intl.locale.requested key?

The SUMO part is likely bug 1523590, not sure how many resources we have working on SUMO these days.

@zibi
Is there a known way for the code to get a "und" locale?

Flags: needinfo?(francesco.lodolo) → needinfo?(gandalf)

We only have telemetry data about intl fields from 66 (which explains the bump, this query is about any channel)
https://sql.telemetry.mozilla.org/queries/61987#159422

(In reply to Francesco Lodolo [:flod] from comment #7)

In about:config, do you have a intl.locale.requested key?

The SUMO part is likely bug 1523590, not sure how many resources we have working on SUMO these days.

@zibi
Is there a known way for the code to get a "und" locale?

In about:config when I search for intl.locale.requested it's found but there is no value. I don't know if it's because it doesn't exist and it suggest me to create it or if doesn't exist at all.

(In reply to Anthony B from comment #9)

In about:config when I search for intl.locale.requested it's found but there is no value. I don't know if it's because it doesn't exist and it suggest me to create it or if doesn't exist at all.

Can you add a screenshot to double check? Normally, it shouldn't exist at all, so you should see a prompt to add new key, and select the type of value.

I wonder if it's a Linux distro issue.

Is there a known way for the code to get a "und" locale?

und is a proper BCP47 locale code and we fall on it [0] when the input is not well formed - https://searchfox.org/mozilla-central/source/intl/locale/MozLocale.cpp#97

Maybe the user's locale could not be converted to BCP47 and we had to fall on it?

[0] http://site.icu-project.org/design/locale/root

Flags: needinfo?(gandalf)

My about.config page with the intl.locale.requested empty option.

On the other hand, such locale should not end up in app-locales, so that looks like a bug in LocaleService language negotiation.

(In reply to Francesco Lodolo [:flod] from comment #10)

(In reply to Anthony B from comment #9)

In about:config when I search for intl.locale.requested it's found but there is no value. I don't know if it's because it doesn't exist and it suggest me to create it or if doesn't exist at all.

Can you add a screenshot to double check? Normally, it shouldn't exist at all, so you should see a prompt to add new key, and select the type of value.

I wonder if it's a Linux distro issue.

The screenshot is added.

A co-worker tested on Mac OS X with its Nightly, the link worked well.

Thanks, it looks like you have an empty key. I've tried creating a new profile on my Ubuntu BM, but this doesn't happen :-\

Ok so the key is empty. I'm on a Ubuntu 18.04 desktop and I downloaded Nightly from the APT depots. Here is my source.list.

cat /etc/apt/sources.list.d/ubuntu-mozilla-daily-ubuntu-ppa-bionic.list
deb http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu bionic main
# deb-src http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu bionic main

Do you use the same on your VM?

(In reply to Anthony B from comment #16)

Do you use the same on your VM?

I had no idea Nightly was available via ppa. No, I'm using the official Nightly decompressed in a folder. Could you try with that instead?
https://www.mozilla.org/en-US/firefox/nightly/all/

(In reply to Francesco Lodolo [:flod] from comment #17)

(In reply to Anthony B from comment #16)

Do you use the same on your VM?

I had no idea Nightly was available via ppa. No, I'm using the official Nightly decompressed in a folder. Could you try with that instead?
https://www.mozilla.org/en-US/firefox/nightly/all/

I tried with Nightly for Linux 64-bit. The links are working so it seems to be only on the PPA.

Priority: -- → P3

So, ppa is setting the default locale to und?

The first thing is that they seem to package language packs for Nightly…
https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+packages

Then they have a vendor-gre.js file in the main .deb

// Use LANG environment variable to choose locale
pref("intl.locale.matchOS", true);

// Enable Network Manager integration
pref("network.manage-offline-status", true);

// Load system dictionaries. Note that this doesn't work in distribution.ini
// because that is applied after addons-startup, when the dictionaries are
// loaded
pref("spellchecker.dictionary_path", "/usr/share/hunspell");

// Use the system locale. Note that this doesn't work correctly in
// distribution.ini as this pref needs to be initialized before
// distribution.ini prefs are applied, in order for locale-specific prefs
// to work
pref("intl.locale.requested", "");
Has STR: --- → yes
Status: UNCONFIRMED → NEW
Ever confirmed: true

Anthony, is the build you test one w/out updater? Then the bugs around bug 1554742 would be related.

See Also: → 1554742

Axel, when submitting this bug I was using the PPA, not the updater. It seems the issue was linked to the locale, set as "und" in the PPA.
Now I am using a Nightly with the updater, no longer from the PPA, and the links work.

When I created a new profile, it had my language (Czech) installed and menus are in Czech. In my original profile, menus were in English and Czech was not available in preferences -> language. When I installed Czech language, links work again.

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:m_kato, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(m_kato)

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #27)

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:m_kato, could you consider increasing the bug severity?

I think that this depends on user configuration, not clean install. So I think this severity is correct. We should investigate whether bug 1554742 still occurs.

Flags: needinfo?(m_kato)

I think I can reproduce the linked 1538027 bug with the last 102.10 release. <input type="file"> was not translated on the first launching, but after a new running, this is fine. It is annoying and a waste of time to understand this bug.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: