392688 - Don't tell SeaMonkey users that SeaMonkey is no longer supported

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect)

Description

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Comment #41 [reply] Chris Thomas (CTho) [formerly [e-mail]]  2007-08-17 16:13:30 PDT

We have SM users with old profiles getting mislead by the mozilla start page:

<friend> What's this about seamonkey being discontinued?
<me> according to whom?
<friend> when i load it up it tells me i need to upgrade to firefox

Can the page UA-sniff for SeaMonkey?  It's reasonable for a user to conclude
the internet suite they downloaded from Mozilla (which happens to be named
"SeaMonkey") is the "mozilla suite" which is no longer supported.

Comment 1

[Robert Kaiser]

Gerv is on holiday again for a week, I'd be glad if we could get something going here even before that.

I think we should sniff for SeaMonkey UAs and redirect them to projects/seamonkey/start/ instead.

Comment 2

[Gervase Markham [:gerv]]

Oops. :-(

I took the .htaccess file out of mozilla.org/start/ - I've put it back again, with the RewriteEngine On and then a hopefully suitable rewrite rule. About an hour from now, test it again. If it still doesn't work, you'll need to tweak the rewrite rule until it does the right thing.

Gerv

Comment 3

[Robert Kaiser]

Thanks for the fast response!

I just looked at the .htaccess and wonder if the ^ in front of SeaMonkey is right - I'd guess it's marking the beginning of the UA, where we have "Mozilla" just like everyone else. I think we just need to remove that ^ sign there.

Comment 4

[Gervase Markham [:gerv]]

KaiRo: You are, indeed, right. Fixed.

Gerv

Comment 5

[Gervase Markham [:gerv]]

It still doesn't seem to be working. I wonder if there's some magic about this... CCing justdave. Reed?

Gerv

Comment 6

[Robert Kaiser]

From what I heard, the problem is probably that netscalers are caching the page and the .htaccess isn't used on a normal access as the normal apache doesn't even get the request in the vast majority of cases, so SeaMonkey users get the cached page that is the same that anyone else gets.

Reed, any progress on an alternate approach yet?

Comment 7

[Robert Kaiser]

Attachment: do the redirect via JS on the client side

Apparently the server-side redirect/rewrite doesn't work due to the netscaler caching the page.
Because of that, we need to do this client-side with JS, which I'm doing with this patch.

Additionally to the patch itself, the .htaccess can be cvs removed again as it doesn't work anyways.

Comment 8

[Reed Loden [:reed]]

Comment on attachment 277722 [details] [diff] [review]
do the redirect via JS on the client side

>+<script type="text/javascript"> <!--

Nit: Please put the "<!--" on its own line.

r=me

Comment 9

[Robert Kaiser]

(In reply to comment #8)
> Nit: Please put the "<!--" on its own line.

Sure, I just had copied this from an older version of this <script> block.

I just realized I can't check into the start pages partition - apparently this is different again from the frontpages partition I got access to in bug 349501...

Reed, could you check this in for me with the nit fixed and along with the .htaccess removal?

Comment 10

[Reed Loden [:reed]]

Checking in .htaccess;
/www/mozilla-org/html/start/.htaccess,v  <--  .htaccess
new revision: 1.7; previous revision: 1.6
done
Checking in index.html;
/www/mozilla-org/html/start/index.html,v  <--  index.html
new revision: 1.63; previous revision: 1.62
done

I'll wait for the production site to update, and then I'll remove .htaccess completely.

Comment 11

[Reed Loden [:reed]]

Removing .htaccess;
/www/mozilla-org/html/start/.htaccess,v  <--  .htaccess
new revision: delete; previous revision: 1.7
done

Comment 12

[Bruno 'Aqualon' Escherl]

Do we care about Iceape users? They still get that warning, cause the UA doesn't contain SeaMonkey.

The UA-String here is Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13pre) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.10~pre070720-0etch3)

Comment 13

[Robert Kaiser]

I for myself don't care about IceApe, as it's no mozilla.org product and this is a mozilla.org page. I wouldn't even know where to redirect them to, the SeaMonkey start page is clearly wrong as it's not SeaMonkey by definition. And then, just redirecting to an external, non-mozilla.org site would probably be a bad idea as well.
If Debian cares about it, they should file a new bug and attach an additional patch, but it's not our duty to clean up a mess they invented in the first place.

Comment 14

[Gervase Markham [:gerv]]

I'm not entirely happy about this solution, because it fails for people with JS turned off. How much do we care about that?

Does this netscaler problem mean that all .htaccess-based stuff across the website doesn't work? Including access control? Isn't that a security problem?

Gerv

Comment 15

[Reed Loden [:reed]]

(In reply to comment #14)
> Does this netscaler problem mean that all .htaccess-based stuff across the
> website doesn't work? Including access control? Isn't that a security problem?

NetScaler caching just means we can't do anything dynamic (such as user agent checking) on the server-side. All dynamic stuff must be done client-side with JavaScript. On www.mozilla.org, .htaccess works fine normally for redirecting and such, but it will not work well for dynamic checks.

As far as I know, nothing on www.mozilla.org or www.mozilla.com uses .htaccess files for access control, so that has no bearing on this matter.