When I click the addon manager's link to the plugin check website, I end up at https://www.mozilla.com/en/404 (which for whatever reason is using the Student Reps theme). That seems wrong. The link from about:plugins works, for whatever that's worth. I'm using the latest Nightly build as of mid-day Friday. In about:config, "plugins.update.url" is set to the default "https://www.mozilla.com/%LOCALE%/plugincheck/". (Which, when I replace %LOCALE% with "en-US", leads me to that same 404 error page.)
So fun story: The link from about:plugins points to http://www.mozilla.com/plugincheck/ which redirects to http://www.mozilla.org/en-US/plugincheck/ http://www.mozilla.org/en-US/plugincheck/ is exactly what plugins.update.url ends up using after replacing the locale, except the working version uses "http", not "https".
> I'm using the latest Nightly build as of mid-day Friday. Apologies for the spam, thought I should add that I'm seeing this in Nightly, but I only spotted this from a MozillaZine post from people running the release version of Firefox 12, if that affects the severity or priority for getting this looked at...
WORKAROUND: Append the following to user.js. user_pref("plugins.update.url", "http://www.mozilla.com/%LOCALE%/plugincheck/");
Other workaround: replace .com by .org in the plugins.update.url pref. Dupe of bug 752178?
Workarounds are nice, but this bug needs to be fixed since it impacts security and since it appears in both the released as well as in the Nightly builds. I would bump the priority to critical, especially since it seems like it should be an easy fix.
Affects both Firefox and Thunderbird latest releases.
May be OS X only; just tested on Windows 7 and plugin update seems to work fine.
(In reply to David Jackson from comment #8) > May be OS X only; just tested on Windows 7 and plugin update seems to work > fine. Nope. I've seen it Windows 7 for the past several days.
It will be fixed by bug 752232.
As per comment by Wes: Gone to about:config and plugins.update.url and changed path from .com to .org and left https (notice "s" on end) and then closed browser and re-opened and gone to add-ons and clicked link. Works flawlessly! fixed TY for info Wes. I agree that for most instances, need to recheck all links to Mozilla and ensure ".org" where appropriate are affixed to all web pages on servers.
just updated to 12.0 and the exact issue is still there ... applying workaround on my machine worked ... since this is an easy fix, I expect that it will be fixed in the next incremental update ...
FF 12.0.0 I have encountered the same problem with both my default profile and a test profile I created for testing. The test profile is in its virgin state with no changes to the default settings. My exact path to receive the error is: tools > add-ons > plugins (in the add-ons manager window) > "Check to see if your plugins are up to date" (hyperlink) This directs to https://www.mozilla.com/en/404 which is a web page titled "Mozilla Student Reps" which displays this error message: Sorry We couldn't find the page you're looking for I hope the more detailed step-wise process along with the information that indicates that extensions and plugins are not part of the problem proves to be helpful in resolving this issue.
Thanks for you help but the problem is well understood (even if the primary cause is unknown) and will be fixed by bug 752232 during working days.
This should be fixed now. As a related bug, what does it take to have this default URL changed in the Addons Manager to point to www.mozilla.org instead of .com? I mean, upstream in a future release. We should endeavor to save all users a redirect (and DNS lookups) here. Fewer steps is both faster and more reliable (fewer things in line that can break).
thanks ... works good now
(In reply to Jake Maul [:jakem] from comment #21) > As a related bug, what does it take to have this default URL changed in the > Addons Manager to point to www.mozilla.org instead of .com? I mean, upstream > in a future release. We should endeavor to save all users a redirect (and > DNS lookups) here. Fewer steps is both faster and more reliable (fewer > things in line that can break). Change http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#618 and you should be good to go.
Created attachment 621485 [details] [diff] [review] s/com/org Something like this. Gavin, can you review this? It changes the plugin update URL from pointing at mozilla.com to mozilla.org, which cuts down a redirect for everyone clicking the "check for updates" link.
Comment on attachment 621485 [details] [diff] [review] s/com/org This is probably not the right bug to be doing this in, but sure, this looks fine. I think there was another tracking bug on file to do all these switches across the board (we have a lot of in-product mozilla.com links that need to be updated).
(In reply to Scoobidiver from comment #16) > Thanks for you help but the problem is well understood (even if the primary > cause is unknown) and will be fixed by bug 752232 during working days. There are two issues here. (1) the landing page for 404 errors (see 752232) (2) a typo in the plugins.update.url config (should be http://www.mozilla.com/%LOCALE%/plugincheck/, not https://www.mozilla.com/%LOCALE%/plugincheck/). It's getting a bit unclear as to which tracker is for which issue...
(In reply to Erik Blake from comment #26) > (2) a typo in the plugins.update.url config (should be > http://www.mozilla.com/%LOCALE%/plugincheck/, not > https://www.mozilla.com/%LOCALE%/plugincheck/). It's getting a bit unclear > as to which tracker is for which issue... Why do you think this is a typo? It makes sense to me that we'd use https wherever possible - prior to bug 752232 (and now that it is fixed), this works fine.
Can the patch land on m-c?
I just pushed this to inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/b613ac5ff64a