If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Find Updates for plug-ins can lead to the wrong page.

RESOLVED INCOMPLETE

Status

Websites
plugins.mozilla.org
--
major
RESOLVED INCOMPLETE
7 years ago
5 years ago

People

(Reporter: Michael Buckley, Unassigned)

Tracking

Details

(URL)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Ubuntu/10.10 (maverick) Firefox/3.6.12
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Ubuntu/10.10 (maverick) Firefox/3.6.12

I went to Tools -> Add-ons -> Plugins -> Find Updates and it took me to https://www.mozilla.com/en-US/en-AU/plugincheck/ which is a 404.  Not good.

Reproducible: Always
Status: UNCONFIRMED → NEW
Component: General → plugins.mozilla.org
Ever confirmed: true
Product: Firefox → Websites
QA Contact: general → plugins-mozilla-org
(Reporter)

Updated

7 years ago
Summary: Find Updates for plugs can lead to the wrong page. → Find Updates for plug-ins can lead to the wrong page.

Comment 1

6 years ago
This may be an ubufox bug, as I don't believe we provide "find updates" in the stick versionf of Firefox. Chris, could you comment on whether this is an ubufox function and, if so, where a bug should be filed?

Comment 2

6 years ago
Hi,

This doesn't look like it comes from Ubufox. There is a "Check to see if your plugins are up to date" link in the plugins tab of about:addons on my install by default, which directs to https://www.mozilla.com/%LOCALE%/plugincheck/ (set in plugins.update.url).

This works for most locales, eg https://www.mozilla.com/en-GB/plugincheck/ and https://www.mozilla.com/de/plugincheck/ both work fine, but https://www.mozilla.com/en-AU/plugincheck/ gets redirected to the broken URL

Comment 3

6 years ago
Oh, where did en-AU come from?

Comment 4

6 years ago
No idea. I'll definitely get the redirect looked at, but the locale usually comes from the browser, but the UA string is en-US, so I'm a little baffled.

Comment 5

6 years ago
Ok, ubufox provides en-AU translations for its own chrome, and it also sets general.useragent.locale to a localized value (I'm not entirely sure why). However, I still can't recreate the reporters issue if I set general.useragent.locale to en-AU (or if I run with LC_ALL=en_AU.UTF.8) on the current Firefox beta.

The %LOCALE% part of the URL is substituted with the locale for the global chrome package, which is "en-US" when you run with en-AU (because there aren't any en-AU translations for the global package), and this seems to be working as expected here.

Comment 6

6 years ago
Huh, even weirder, language-pack-en-base contains en-AU translations, which is why it's broken :/

I'm trying to find out where they have come from and why they are there.
(In reply to Chris Coulson from comment #6)
> Huh, even weirder, language-pack-en-base contains en-AU translations, which
> is why it's broken :/
> 
> I'm trying to find out where they have come from and why they are there.

Hey Chris, can we close this bug since it seems not related to our website ?
resolving incomplete, feel free to reopen if this is still a bug that is on the mozilla site
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.