332818 - Redirect to SeaMonkey subsite from root depending on user agent

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Public Pages, enhancement)

Description

[Sander]

Running a SeaMonkey build - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20060309 SeaMonkey/1.1a - the new update shows me Firefox extensions by default, rather than Mozilla Suite.
Together with bugs like missing appfilter variables in category links, this means that browsing extensions becomes very hard for SeaMonkey users.

Comment 1

[Cameron]

Is this seamonkey specific, or does it occur with the suite aswell?

Comment 2

[Sander]

Hendikins and Nemo just tested this (with a windows and a linux version of 1.7.x respectively), and they both get the Firefox skin as well.

Comment 3

[Marcia Knous [:marcia]]

Same thing happens when running a Thunderbird build - I get the Firefox Add-ons. Since I suspect one fix may nail this all, I won't file a new bug unless morgamic tells me to do so.

Comment 4

[alanjstr]

Related to bug 276243

Comment 5

[Sander]

What was fixed was bug 332819. Morphing this to discuss a solution to get the old AMO behaviour back where some UA-string detection is done to by default always show the right extensions for the used product. Quoting from IRC:

<Sander> It definitely would provide a much nicer experience for suite users if they get the "right" frontend right away (so that if they click on the big extensions link, they'll get suite extensions, and not firefox ones)
<morgamic> because if we cache based on UA
<morgamic> we split the cache even more
<morgamic> and we lose performance
<morgamic> so it might not be a good idea
<morgamic> why risk it?
<Sander> Because now they will by default be presented with extensions that won't work for them.
<tH> i think things would be best off as seperate sites, but with / being a ua-based redirect that isn't cached
<Sander> Could there be a UA string redirect to /seamonkey/ before pulling from cache kicks in?
<morgamic> hmmm
<Cameron> couldn't you just have like a pre-page that detects the ua when they come to addons.mozilla.org, and then it adds a little ?= thing to the url and then it goes to the cached version of the site
<Cameron> bleh I'm slow
<morgamic> yeah, we could do that
<morgamic> Sander: okay -- how about we reopen the bug and discuss a better solution

Comment 6

[Cameron]

Organising bugs. Sorry for the bugspam.

Comment 7

[Mike Shaver (:shaver emeritus)]

Let's try to get this in the 2.1 update, though I suspect that we'll need to do some noodling on how we want the multi-app stuff to work in general.  (TBird should probably go to a /thunderbird/?version=%APP_VERSION% sort of page from its UI, additionally.)

Comment 8

[Mike Shaver (:shaver emeritus)]

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

Comment 9

[Wil Clouser [:clouserw]]

Changing target to remora and releasing

Comment 10

[Mike Shaver (:shaver emeritus)]

I think this is WONTFIX; suite users should get in-product links to the right part of the site, and otherwise it's very very likely that users want to go to the Firefox page even if they aren't using Firefox as their browser.  Boldly resolving!

Comment 11

[Sander]

Re-opening. Respectfully, I think you're on crack.
SeaMonkey users in particular are the kind of people who will manually type in addons.mozilla.org in their browser. (I'm not proposing to redirect old suite users; that's not a battle I'm interested in fighting.) SeaMonkey has a separate section at AMO. SeaMonkey has a uniquely identifiable user_agent string. It doesn't hurt anyone else anything at all to HELP these users and automatically redirect them to what - with 99% certainty - is the CORRECT part of the site for them, rather than to the wrong part.

I'm more than willing to do the work needed for this too. Looks like a one-line addition here: http://lxr.mozilla.org/webtools/source/addons/public/inc/init.php#179 - although naturally enough I'd need to spend half a day tracing dependencies to be certain that won't have unintended consequences.

If you want to generalize things, and do this for Thunderbird (someone could theoretically set AMO as its startpage) and Sunbird (?) too, I'd be more than happy to take care of that, too. Just let me know what will be acceptable/required to get this accepted.

Comment 12

[Sander]

*sheepish* uhm, yeah, it'd have helped if I was browsing under /remora/ rather than /addons/. Either way, I'm still willing to do the work, though I'll need to retrace to find out where to make the fix. :)

Comment 13

[Justin Scott [:fligtar]]

The remora directory in CVS hasn't been touched in 8 months.

http://svn.mozilla.org/addons

Comment 14

[Wil Clouser [:clouserw]]

Any changes to the code will only be useful for people who are logged in (and, in fact, should only be processed if someone is logged in), as the rest of the time pages are cached.  (fyi)

Comment 15

[Mike Shaver (:shaver emeritus)]

We don't cache the front-page redirect already, because it does language detection, actually.

Comment 16

[Sander]

Attachment: Detect SeaMonkey for redirect

I've gone for the simplest solution here. If you'd like me to do more robust user_agent sniffing, or to generalize this to take into account Thunderbird and Sunbird (since hypothetically those could be used to browse to AMO too) as well, let me know.

Comment 17

[Mike Shaver (:shaver emeritus)]

Thanks for the patch.  Can you please add a test to the suite for this?  Given the relatively low (perhaps zero) size of the active AMO developers who use SeaMonkey, I suspect it would be subject to random breakage.

I also think that we should just do this for the root page, not in the general recovery case, FWIW.

Comment 18

[Basil Hashem [:baz]]

Submitting for consideration for AMO v3.2 (Redesign)

Comment 19

[Michael Morgan [:morgamic]]

Comment on attachment 265312 [details] [diff] [review]
Detect SeaMonkey for redirect

Won't work with caching.  We should explore setting up NS rules to redirect users based on user agent.

Comment 20

[Michael Morgan [:morgamic]]

Jeremy and Matthew -- would it be possible to add an NS rule to accomplish this?

Comment 21

[Mike Shaver (:shaver emeritus)]

The root page already does detection and redirection for language, as seen in the bottom of the context of this diff, so I'm not sure why this wouldn't work?

(Can we just have Vary: yet? All the other caching systems on the web are laughing at us. :( )

Comment 22

[Fred Wenzel [:wenzel]]

(In reply to comment #21)
> The root page already does detection and redirection for language, as seen in
> the bottom of the context of this diff, so I'm not sure why this wouldn't work?

Incidentally, that's the same question I asked in bug 353208 comment 7; once it is answered, we can do UA sniffing magic for both AMO and MDC (different context, same thing).

Comment 23

[Michael Morgan [:morgamic]]

Fred, can you retest the patch on your install and give us the results?

Comment 24

[Fred Wenzel [:wenzel]]

Comment on attachment 265312 [details] [diff] [review]
Detect SeaMonkey for redirect

Yes, I can, no prob:

The patch wfm. However this may NOT be checked in before we figured out the Netscaler side of things.

Comment 25

[Fred Wenzel [:wenzel]]

Also, this needs a test. Without one, this would be prone to random breakage because I don't think any of the devs use Seamonkey as their primary browser.

Comment 26

[Fred Wenzel [:wenzel]]

Discriminating by UA seems to be fine on the cache side (see bug 353208 comment 10 sqq.).

I'll write a test, then we can check this in.

Comment 27

[Robert Kaiser]

(In reply to comment #26)
> Discriminating by UA seems to be fine on the cache side

Interesting. I seem to remember that such things did not work for www.mozilla.org when we wanted to redirect SeaMonkey users from mozilla.org/start to the SeaMonkey start page, and we had to do that via JavaScript, as the Netscaler cached the same version of the page for all UAs.

Comment 28

[Fred Wenzel [:wenzel]]

(In reply to comment #27)
> (In reply to comment #26)
> > Discriminating by UA seems to be fine on the cache side
> 
> Interesting. I seem to remember that such things did not work for
> www.mozilla.org when we wanted to redirect SeaMonkey users from
> mozilla.org/start to the SeaMonkey start page, and we had to do that via
> JavaScript, as the Netscaler cached the same version of the page for all UAs.

Yeah, I feared this was going to happen too which is why I asked IT beforehand (see the other bug).

Comment 29

[matthew zeier [:mrz]]

I could be wrong - can you give me a test case?  And perhaps send out no-cache headers with your 302?

Comment 30

[Fred Wenzel [:wenzel]]

(In reply to comment #29)
> I could be wrong - can you give me a test case?  And perhaps send out no-cache
> headers with your 302?

Ah no prob, and sorry for the misunderstanding. This bug is indeed about sending out a 302 based on UA (which, much like the language redirect we are doing, will include sending no-cache headers and to my knowledge this works). So I think we are golden over here.

Bug 353208, however is about sending a 200 result with different content based on UA; so let's handle this over there.

Comment 31

[Fred Wenzel [:wenzel]]

Alright, I wrote a test that makes sure seamonkey is redirected correctly. All of this is in SVN r9140. Marking this fixed, yet it won't show up online until the next time we push.

Thanks, everyone.

Comment 32

[Justin Scott [:fligtar]]

This is live.