294144 - VersionCheck.php doesn't work if the user's UserAgent is screwed up by an extension

Status: RESOLVED WONTFIX

(mozilla.org Graveyard :: Server Operations, task)

Description

[hunk4004]

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.

Comment 1

[Colin Ogilvie [:cso]]

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.

Comment 2

[alanjstr]

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,

Comment 3

[alanjstr]

*** Bug 294297 has been marked as a duplicate of this bug. ***

Comment 4

[alanjstr]

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).

Comment 5

[alanjstr]

*** Bug 294781 has been marked as a duplicate of this bug. ***

Comment 6

[Dave Miller [:justdave]]

Attachment: JS test with instructions

This adds a javascript test for a UserAgent string with a space after the
Firefox version number.  If this is detected, it unhides an initially-hidden
<div> with instructions to tell the user how to fix it.  The wording of the
instructions needs marketing review.

Comment 7

[Dave Miller [:justdave]]

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.

Comment 8

[alanjstr]

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)

Comment 9

[alanjstr]

*** Bug 294998 has been marked as a duplicate of this bug. ***

Comment 10

[Dave Miller [:justdave]]

(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.

Comment 11

[Dave Miller [:justdave]]

Attachment: 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. :)

Comment 12

[Dave Miller [:justdave]]

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

Comment 13

[VanillaMozilla]

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.

Comment 14

[alanjstr]

VersionCheck and the ExtensionManager do not use vendorSub.  They use
app.extensions.version

Comment 15

[Dave Miller [:justdave]]

(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.

Comment 16

[Dave Miller [:justdave]]

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.

Comment 17

[Dave Miller [:justdave]]

Justin is now the QA for this component.

Comment 18

[Dave Miller [:justdave]]

Not sure if we still care on this...  what's product management think?  cbeard?

Comment 19

[Jeremy Orem [:oremj]]

This looks like a addons problem not a server operation problem.

Comment 20

[Michael Morgan [:morgamic]]

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.

Comment 21

[Michael Morgan [:morgamic]]

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 1.5.0.6 would have 1.5.0.6 _somewhere_ in the UA string?

Comment 22

[Dave Miller [:justdave]]

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.

Comment 23

[Jeremy Orem [:oremj]]

No action on this for a long time, please reopen if someone is still having problems.

Comment 24

[Michael Morgan [:morgamic]]

WFM! :)