Addons-frontend: Seamonkey and thunderbird should always get legacy amo

[muffinresearch]

The new frontend looks suboptimal in SeaMonkey and since the new frontend has no support for Seamonkey or Thunderbird it would make sense to _always_ (irrespective of mamo cookie settings) send requests with a SeaMonkey or Thunderbird UA to the legacy AMO.

Later we can move this to serve the thunderbird and seamonkey specific site when it's available.

I think you can just look for "seamonkey" (case-insensitive) in the UA string for SeaMonkey and "thunderbird" for Thunderbird.

Here's an example seamonkey UA string:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48

And one for Thunderbird - I just pulled this one from a UA site.

Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

In general thunderbird is less of an issue because it tends to use urls that are specific and contain the thunderbird client application.

[muffinresearch]

@bqbn apologies for the short notice, would it be possible to add something that we can test out on -dev and stage this week with a view to putting out with the new frontend release?

[bqbn]

The change is in -dev and -stage now.

Please test.

[kumar303]

Thanks @bqbn, it worked for me. I realized that we need to handle user agent redirects so I filed https://github.com/mozilla/addons-frontend/issues/3728

[muffinresearch]

@bqbn - looks good with SeaMonkey if I set the mamo cookie to "off" I still get the legacy site everywhere.

I don't seem to be able to find a path to look at amo pages within Thunderbird itself, but using a UA switcher with a current UA string it all looks good.

[muffinresearch]

Closing this issue should make it more visible to QA.

[muffinresearch]

QA Notes:

You should find if you use a Thunderbird or SeaMonkey UA navigating to stage should give you the old site. It's important to try using a URL that doesn't contain seamonkey or thunderbird since those are explicitly not routed to the new frontend.

The about page is a good example of that. You should get the old site irrespective of the cookie settings.

[ValentinaPC]

Verified this on AMO-stage FF56(Win 7) and encountered the following scenario:

1. Load old AMO homepage - https://addons.allizom.org/en-US/firefox/
2. Go to Thunderbird homepage - https://addons.allizom.org/en-US/thunderbird/
3. Pick an add-on that is only compatible with Thunderbird or/and Seamonkey i.e. "Signature Switch"
4. Go to its manage page https://addons.allizom.org/en-US/developers/addon/signature-switch/versions/1665910
5. Open AMO homepage in a new tab and select "Visit the new site"
   6 Go to the tab where page from step 4 is, and click "View Listing"
6. Add-on details page using the new design is loaded for that add-on

This is not happening if we use 1 tab.
I know its an edge case. :)
Links from "About" page works as expected.

[muffinresearch]

@ValentinaPC are you using a SeaMonkey or a Thunderbird user-agent string?

I'm not sure I follow your STR. Does the new tab have the right user-agent string? Kumar found yesterday that some user-agent string extensions are buggy.

Another way to test is to actually use SeaMonkey.

[ValentinaPC]

Yes....I missed the part that implied changing the user agent. :(

Verified again in AMO-stage using Thunderbird and SeaMonkey user agents as follows:

In a new FF58 profile I changed the agent first to "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 SeaMonkey/2.48" and the above scenario was invalid :)
Also changing the app to "Firefox" from AMO and clicking on "Visit the new site" will not redirect to the new AMO pages - which I suppose it is ok because of the user agent, yes @muffinresearch ?

Then, I changed the user agent to "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Thunderbird/31.2.0" and checked again things worked as expected.

Sorry for misunderstanding.

[muffinresearch]

@ValentinaPC yep with a thunderbird or Seamonky UA you should never see the new frontend.

[ValentinaPC]

Marking this as verified fixed!