Closed
Bug 609857
Opened 14 years ago
Closed 12 years ago
Find Updates for plug-ins can lead to the wrong page.
Categories
(Websites :: plugins.mozilla.org, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: testo.moz, Unassigned)
References
()
Details
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
Updated•14 years ago
|
Status: UNCONFIRMED → NEW
Component: General → plugins.mozilla.org
Ever confirmed: true
Product: Firefox → Websites
QA Contact: general → plugins-mozilla-org
Reporter | ||
Updated•14 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•14 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•14 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•14 years ago
|
||
Oh, where did en-AU come from?
Comment 4•14 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•14 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•14 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.
Comment 7•14 years ago
|
||
(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 ?
Comment 8•12 years ago
|
||
resolving incomplete, feel free to reopen if this is still a bug that is on the mozilla site
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•