246746 - Browser detection broken on front page

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect, P1)

Description

[KDS]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7

When one visits http://update.mozilla.org/index.php (or
http://update.mozilla.org) the right corner has the Firefox Logo. The firefox
logo on default page suggests it might be Firefox specific page.
As the update site says "Mozilla Update hosts Extensions and Themes for Mozilla
software.", the default page should only have a Mozilla Org logo. Another
suggestion: make the page dynamic by guessing the browser and automatically
taking the user to the page serving extensions and themes for that browser.

Reproducible: Always
Steps to Reproduce:
1. Go to update.mozilla.org
2.
3.



Expected Results:  
There should be either no Firefox logo or dynamic browser checking should
automatically take the visitor to the browser's page which user is using.

PS: Similar request for http://update.mozilla.org/faq/
It also has Firefox logo on right.

Comment 1

[alanjstr]

Well, when I visit with Firefox, it shows the firefox logo.  If I click the
Mozilla tab, it shows nothing.  The TB tab shows the TB logo.  So I would say
that the problem is browser detection.  Same goes for the FAQ.  There are
different FAQs.

Comment 2

[Wolf [:wolf]]

The frontpage is supposed to support more than one browser/product on arrival.
Looks like it's not handling Mozilla 1.x correctly.

The FAQ page this doesn't apply to, it takes whatever variable is passed to it.
for the masthead.

Confirming.

Comment 3

[Wolf [:wolf]]

Firefox is default, so that summary is invalid.. If there was another product to
detect, it'd have been clearer though. the original is more accurate. really. :-)

Comment 4

[Wolf [:wolf]]

Working on this. :-)

Comment 5

[Wolf [:wolf]]

OK, got this fixed, locally.. It now understands the visiting application and
detects on a global level.
For non-mozilla.org browsers, it defaults to Firefox. but the fix here opens up
the possibility to perhaps in the future let the user specify the perferred
default. and store it.

Comment 6

[Wolf [:wolf]]

Fixed.

Comment 7

[alanjstr]

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

Comment 8

[alanjstr]

Ok, the squid proxy is caching OS when OS is not in the URL.  

Comment 9

[alanjstr]

As discussed in IRC:
Send a simple page with a javascript redirect to send us OS if OS wasn't passed
already.  The simple page should also let the user select their OS/browser/etc
and redirect themselves if they have js turned off.

This would apply to index.php, showlist.php

But not moreinfo.php, maybe

Comment 10

[Wolf [:wolf]]

If they have JS off, defaults are fine. :-) No intermediate page that requires
user-intervention should appear. moreinfo.php requires the values as well, but
in general, it handles things more gracefully.

Comment 11

[alanjstr]

But its not defaulting.  Its showing them the wrong thing.

Comment 12

[Dan]

(In reply to comment #11)
> But its not defaulting.  Its showing them the wrong thing.

Not sure of the status of this, but now there is a possibly related problem with
the browser detection..

Clicking to view any extension page from the "Newest" list of Firefox
extensions, with Firefox 1.0 milestone, it shows the following message:

"Incompatible Extension or Extension No Longer Available
The extension you requested is either incompatible with the application
selected, or the version of it is no longer available on Mozilla Update.

To try your request again for a different application version, use the form below."

The selected option in the list of applications is Firefox 1.0+, which indicates
it's either incorrectly reading the browser version, or defaulting to 1.0+
without checking..

To be clear, when selecting Firefox 1.0 from the list of browser versions and
clicking "Go", it shows the correct extension page.

I was going to file a separate bug, but I wasn't sure whether version checking
was being worked on already on the basis of this bug, or if it was a side-effect
from changes introduced from fixing this bug..

Comment 13

[alanjstr]

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

Comment 14

[Chris Mathieson]

(In reply to comment #12)

> "Incompatible Extension or Extension No Longer Available
> The extension you requested is either incompatible with the application
> selected, or the version of it is no longer available on Mozilla Update.

I got the same error message after installing v1.0.1; I'm not sure what version
it's detecting, but it's not defaulting to 1.0+... I have to manually change the
version when searching for extensions.

Comment 15

[alanjstr]

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

Comment 16

[alanjstr]

From the bottom of http://www.stumbleupon.com/inc_browserdetection

Modified to be reused on pages other than index.php and to re-use the global
function $uriparams

// Geoff's hack to get past squid's annoying caching issues
// by putting os/application/etc.. directly into the url
// only potention problem is if squid caches this 302 redirect
// in which case all hope is lost
if (!isset($_GET['os']) 
  || !isset($_GET['application'])
  || !isset($_GET['app_version']) )
{
  // we need to do 302 redirect to an URL
  // that has the OS, browser, and browser version
  // so squid can actually cache this page properly
  $location =
"$_SERVER['PHP_SELF']?os=$OS&application=$application&app_version=$app_version&$uriparams";
  
  header("Location: $location");
  exit();
}

Comment 17

[Geoff Smith]

Attachment: Fixes browser detection problems in relation to squid

This patch should deal more reasonably with invalid input for os, application,
and version.  It also uses a 302 redirect to send people to a cacheable page
that will work with Squid.

The way it works now, if someone shift-reloads the extensions page as a Linux
Mozilla 1.2 user, the next person to come there will get the cached page for
that os/application/version even if they are say running Firefox 1.0.3 on
Windows.

This will fix that problem, and 302's should incur minimal overhead.

I've also added a couple 2 line changes to get rid of some PHP unset variable
warnings.

This patch probably needs considerable testing as it activates on any page that
uses browser detection, and the current code for detecting browsers is messy
and confusing, and it's possible I removed something that was necessary by
accident.

Once this patch is deployed, it should be followed with patches to use
OS/application/version properly on all pages.  In particular,
extensions/index.php will currently show you Windows-only extensions even if
you are a Linux or Mac user.

Comment 18

[Geoff Smith]

It appears my previous patch may break commenting.  Just a heads up.

Comment 19

[Geoff Smith]

Comment on attachment 180925 [details] [diff] [review]
Fixes browser detection problems in relation to squid

This should no longer be necessary now that squid has been fixed.

Comment 20

[alanjstr]

Squid wasn't fixed, it was replaced with apache on the front and a vary on the
useragent.

Comment 21

[Stephen Donner [:stephend] Not actively reading bugmail]

This has long since been fixed (esp. with Remora 3.2); verified.