If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

/firefox redirect not working as expected for old versions of Firefox

VERIFIED FIXED

Status

www.mozilla.org
General
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: cmore, Assigned: pmac)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sp-2012-08-14] u=dev c=general p=2)

(Reporter)

Description

5 years ago
Steps to reproduce:

1) Load Firefox 3.6

2) Visit http://www.mozilla.org/firefox

Expected:

* Page loaded: http://www.mozilla.org/en-US/firefox/new/

Actual:

* Page loaded: http://www.mozilla.org/en-US/firefox/fx/

The .htaccess code is on line 401:

http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/.htaccess?view=markup

It should redirect version 13-16 of Firefox visits to /firefox to /firefox/new and all other versions to /new.

It works as expected if the locale is in the URL. For example:

* http://www.mozilla.org/en-US/firefox/ (redirects to /firefox/new/)
* http://www.mozilla.org/firefox/ (redirects to /firefox/fx/)

Raymond: Can you verify this situation? Try both of URLS right above this line.
(Reporter)

Comment 1

5 years ago
Raymond/Rik: What automated tests do you have in place for this redirect?

Comment 2

5 years ago
Thanks for catching the root cause here, Chris. In terms of timing this is very important to get fixed as soon as we can - it is throwing off multiple engagement campaigns that we have set around the redirect logic that isn't in place.
(Reporter)

Comment 3

5 years ago
There is a high probability that this was been like this for quite a while, but it hasn't been an issue since historically /fx and /new were not extremely different. Since they different now and /fx pushes mobile first, we have a UX issue.

This is why I honestly think we need to simplify Mozilla.org and the Firefox pages much more because the complexity of the .htaccess file, redirects, and many pages make it possible to break very easily. The .htaccess file is huge and it is nearly impossible to write tests to see which rewrites are needed and which are obsolete. We continue to do band aide fixes to Mozilla.org and all the legacy stuff makes it really difficult to do strategic things going forward. I vote for a complete "reset" once the Product Manager for Websites gets on board. We can fix and improve things now in important areas, but there needs to be an overhaul of the IA/UX on the website.
See test_redirect_old_firefox and test_redirect_locale_old_firefox at https://github.com/mozilla/mcom-tests/blob/master/tests/test_redirect_landing.py#L51

This was done on purpose for the Android launch. See similar comments on bug 775454.
(In reply to Chris More [:cmore] from comment #3)
> There is a high probability that this was been like this for quite a while,
> but it hasn't been an issue since historically /fx and /new were not
> extremely different. Since they different now and /fx pushes mobile first,
> we have a UX issue.
> 
> This is why I honestly think we need to simplify Mozilla.org and the Firefox
> pages much more because the complexity of the .htaccess file, redirects, and
> many pages make it possible to break very easily. The .htaccess file is huge
> and it is nearly impossible to write tests to see which rewrites are needed
> and which are obsolete. We continue to do band aide fixes to Mozilla.org and
> all the legacy stuff makes it really difficult to do strategic things going
> forward. I vote for a complete "reset" once the Product Manager for Websites
> gets on board. We can fix and improve things now in important areas, but
> there needs to be an overhaul of the IA/UX on the website.

I was able to reproduce. The .htaccess rules on mozilla.org  have become too complex and hard to  keep track of. I agree with your comments above
(Reporter)

Comment 6

5 years ago
More details:

This was done on purpose on June 26th for the Fennec release and documented in bug 767985. *ALL* Firefox users were redirected to /fx and non-Firefox users to /new regardless of the versions. The previous rule would only redirect Firefox to /fx if they were running one of the recent release versions.

How should we fix this?

Remove the #mobile promotion rule and go back to how it was before the Fennec release.

Also, it is being discussed in this bug and not all are in favor in changing it back now:

https://bugzilla.mozilla.org/show_bug.cgi?id=775454#c5
Reading more closely, we have a real bug. en-US/firefox does not redirect to the same place as /firefox.

Before fixing it, it would be nice to know if we can stop doing the special redirect for the Android launch. To be clear this is different than bug 775454.

Bug 775454 is about whether we should present Android related info on /fx
This bug is about where we should redirect old Firefox users. /new or /fx.
(Reporter)

Comment 8

5 years ago
If we remove the special fennec redirects, we should not a problem as the logic in .htaccess and prefetch will match. They do not now because the fennec rule is only in the prefetch file. Laura has instructed us to remove the redirect, which is only a change in the prefetch file.
(Reporter)

Comment 9

5 years ago
This is the previous commit:

http://viewvc.svn.mozilla.org/vc?view=revision&revision=106735

Only the prefetch file should be modified and not the .htaccess file for the Fennec /fx promotion redirects.

Code was added here:

http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/includes/prefetch.php?r1=106735&r2=106734&pathrev=106735

Comment 10

5 years ago
(In reply to Anthony Ricaud (:rik) from comment #7)
> Reading more closely, we have a real bug. en-US/firefox does not redirect to
> the same place as /firefox.
> 
> Before fixing it, it would be nice to know if we can stop doing the special
> redirect for the Android launch. To be clear this is different than bug
> 775454.
> 
> Bug 775454 is about whether we should present Android related info on /fx
> This bug is about where we should redirect old Firefox users. /new or /fx.

Thanks for the clarification, Rik. It gets tricky quickly. 

The objective of this bug should be to direct people not on the most recent version of Firefox to /new instead of /fx. Let's do this ASAP. 

It's fine if on /fx the #mobile promo is showing - or at least - fine for now. Let's keep that decision separate from this bug.
Assignee: nobody → pmac
Committed pmac's patch in r108078
Thanks Craig!
Using Firefox 3.6 on Mac http://www-dev.allizom.org/firefox  goes to http://www-dev.allizom.org/en-US/firefox/new  and Firefox 14 goes to  www-dev.allizom.org/en-US/firefox/fx
Firefox 3.6 Mac  http://www.mozilla.org/firefox/ -->http://www.mozilla.org/en-US/firefox/new
Firefox 14 Mac http://www.mozilla.org/firefox --> http://www.mozilla.org/en-US/firefox/fx
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Reopening since the tests are not updated. Will have a PR for that soon.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
r108086 on stage
r108087 on prod
So the fix in r108078 broke some other redirects.
See http://qa-selenium.mv.mozilla.com:8080/job/mozilla.com.prod/9613/ for the broken tests.
So mobile redirects fixed with r108090.

Fixed the tests to test the new behaviour in https://github.com/mozilla/mcom-tests/pull/71.

Will push to prod once the QA bots are green.
Pushed to stage with r108091 and production with r108092.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
(Reporter)

Comment 21

5 years ago
Raymond: was r108078 QA verified and also to make sure the automated tests were still happy?

Thanks!
verified fixed 

Firefox 3.6 Mac  http://www.mozilla.org/firefox/ -->http://www.mozilla.org/en-US/firefox/new
Firefox 14 Mac http://www.mozilla.org/firefox --> http://www.mozilla.org/en-US/firefox/fx


tests were merged. We are all set for this
Status: RESOLVED → VERIFIED

Updated

5 years ago
Whiteboard: [sp-2012-08-14] u=dev c=general p=2
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.