User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.7.8) Gecko/20050511 Firefox/1.0.1 StumbleUpon/1.9992 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.7.8) Gecko/20050511 Firefox/1.0.1 StumbleUpon/1.9992 I've updated to firefox 1.04 and when i try to go to the extensions, addons ecc. it tells me that i must update?!? Reproducible: Always Steps to Reproduce: 1.Just click on extensions 2. 3. Actual Results: It told me to update to firefox 1.04(which i have done so) Expected Results: it shouldn't of asked me to update since i did already thus making it impossibile to download any extensions ecc.
The reason for the fact it is telling to to continue to update is because you use, or have used, the StumbleUpon extension. Unfortunately, I'm not sure of the instructions for changing this, though.
Assignee: general → Bugzilla-alanjstrBugs
Component: Bugzilla-General → Web Site
Product: Bugzilla → Update
QA Contact: default-qa → mozilla.update
Go to about:config search for useragent look for the vendorSub If it does not say 1.0.4, right click it and choose reset,
*** Bug 294297 has been marked as a duplicate of this bug. ***
Summary: cannot access the addons with FF 104 because it continues to tell me tu update → Tells me to update when I have FX 1.0.4
Whiteboard: Please read comment number 2 and post if you still have a problem
Users need to be more aware of why they're being redirected to the upgrade page. It would be helpful if the user's UA is displayed since that's what we're filtering on. Also, since Stumbleupon causes the UA to be wrong, it would be helpful if we detected if it is installed and suggest the resetting of the vendorSub (or provide a mechanism to do so).
Assignee: Bugzilla-alanjstrBugs → mozilla.webmaster
Severity: major → normal
Status: UNCONFIRMED → NEW
Component: Web Site → email@example.com
Ever confirmed: true
OS: Windows XP → All
Product: Update → mozilla.org
QA Contact: mozilla.update → danielwang
Hardware: PC → All
Whiteboard: Please read comment number 2 and post if you still have a problem
Version: unspecified → other
*** Bug 294781 has been marked as a duplicate of this bug. ***
Assignee: mozilla.webmaster → justdave
Status: NEW → ASSIGNED
Note this is a fairly high priority to get landed... webmaster and the press contacts have been getting lots of email from people getting bit by this.
Severity: normal → critical
You'll also need to detect Ubuntu Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.7.6) Gecko/20050512 Firefox/1.0 (Ubuntu package 1.0.2)
*** Bug 294998 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > You'll also need to detect Ubuntu > > Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.7.6) Gecko/20050512 Firefox/1.0 > (Ubuntu package 1.0.2) It already does. All I'm doing is looking for a space after the Firefox version number, which Ubuntu's UA has. On the other hand, the fix we suggest isn't going to work for Ubuntu since they've actually got 1.0.2 with backports (and why does their UA say 1.0 on the actual Firefox listing?) so resetting their vendorSub is going to make it 1.0.2 which still won't get them in. Guess I need to do a separate detection for Ubuntu and point them at https://bugzilla.ubuntu.com/show_bug.cgi?id=10681 instead. As for setting the rewrite on Addons to let the new fixed Ubuntu package in, I'm not sure I can reliably detect on "Ubuntu package 1.0.2". They didn't change the UA when they applied the security patches, so I've got no way to detect the user has a fixed version. cbeard/chofmann: can I get signoff from someone on the text of the "workaround instructions" in the existing patch on this bug? It might need a little massaging yet from a marketing person to avoid confusing people. I'll have a new patch up soon that does an alternate message for people with Ubuntu to point them at the bug on Ubuntu's bug system.
Created attachment 184206 [details] [diff] [review] Add special-case for Ubuntu I'm going to go ahead and run with this, since we're still periodically getting folks in IRC complaining about it. The marketing folks can fix it Monday if they don't like it. :)
Attachment #184082 - Attachment is obsolete: true
Checking in html/products/firefox/upgrade/index.html; /cvsroot/mozilla-org/html/products/firefox/upgrade/index.html,v <-- index.html new revision: 1.5; previous revision: 1.4 done
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
This bug also has another aspect, so you might need to consider reopening. The other problem is that if an extension can alter the vendorSub string, it can also prevent Fx from updating extensions. If an extension requires a more recent version, then the extension cannot be updated. There are examples of this in the Support Forum, also due to StumbleUpon. If pressed hard enough I suppose I could find one.
VersionCheck and the ExtensionManager do not use vendorSub. They use app.extensions.version
(In reply to comment #14) > VersionCheck and the ExtensionManager do not use vendorSub. They use > app.extensions.version Except that you can't even get to VersionCheck if your UserAgent is fubared. We can't get around that without exposing the security hole again if we were to allow that URL through (any URL on that domain actually delivering content to an old version is a security risk). We probably *can* specifically redirect that URL to some other domain, and make the VersionCheck script available via that domain.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
QA Contact: danielwang → polvi
Summary: Tells me to update when I have FX 1.0.4 → VersionCheck.php doesn't work if the user's UserAgent is screwed up by an extension
Status: REOPENED → NEW
Component: firstname.lastname@example.org → Server Operations
This is a mass-reassign of bugs that I'm not actively working on right at this moment to the default component owner, since we now have a larger IT staff than just me. These bugs will be getting redistributed to other sysadmins as sysadmin time becomes available.
Assignee: justdave → server-ops
Priority: P1 → --
QA Contact: polvi → myk
Justin is now the QA for this component.
QA Contact: myk → justin
Not sure if we still care on this... what's product management think? cbeard?
Assignee: server-ops → nobody
Component: Server Operations → Server Operations Projects
This looks like a addons problem not a server operation problem.
Component: Server Operations Projects → Add-ons
Product: mozilla.org → addons.mozilla.org
Version: other → 2.0
The UA sniffing is done at a much higher level than the app level. Could we make the condition less greedy (only look for the version, maybe, instead of searching for a verbatim UA string)? Either way, AMO is on the app level, so I'd say this is still an IT problem since developers don't have access to the mechanism that is causing the redirections to happen.
Assignee: nobody → server-ops
Component: Add-ons → Server Operations
Product: addons.mozilla.org → mozilla.org
Version: 2.0 → other
So, if package maintainers can't maintain the client version in the UA string properly, there's not a whole lot we can do, then... :( Doesn't it make sense that a package for Firefox 184.108.40.206 would have 220.127.116.11 _somewhere_ in the UA string?
The extension authors who were screwing it up seem to have learned from it, and the extension developer docs explicitly warn against screwing with it now. What's outlined in comment 15 is probably the only possible way to deal with it, but this is ancient enough, I'm not sure it's worth fixing anymore.
No action on this for a long time, please reopen if someone is still having problems.
Status: NEW → RESOLVED
Last Resolved: 13 years ago → 12 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.