Deal with SeaMonkey with Firefox compatibility declared in its UA string

VERIFIED FIXED in 5.12.1

Status

defect
VERIFIED FIXED
9 years ago
3 years ago

People

(Reporter: davemgarrett, Assigned: Callek)

Tracking

unspecified
5.12.1
Dependency tree / graph

Details

Attachments

(1 attachment)

Reporter

Description

9 years ago
Filed per bug 591327 comment 15.
Reporter

Comment 1

9 years ago
Going to addons.mozilla.org with latest SeaMonkey 2.1 Trunk now brings up AMO in Firefox mode instead of SeaMonkey. This is because the new default UA string for SeaMonkey Trunk is now of the form:

Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100908 Firefox/4.0b6pre SeaMonkey/2.1b1pre

A GUI option was added for this new Firefox compatibility token in SeaMonkey, however it is on by default.

The actual pref for this is general.useragent.compatMode.firefox which was added in bug 581008. It also turned it on by default for Fennec, but I'm pretty sure Fennec was already doing something similar. AMO needs to have its UA sniffing updated to send SeaMonkey 2.1 users to the right place.
Reporter

Updated

9 years ago
Summary: Deal with SeaMonkey (or any non-Firefox application) with Firefox compatibility declared in its UA string → Deal with SeaMonkey with Firefox compatibility declared in its UA string
Reporter

Comment 2

9 years ago
SeaMonkey 2.1b1 is currently "scheduled" for sometime next month, which is when it would be nice to have this fixed by as all SeaMonkey beta users would be ending up at the wrong place if not fixed. No way to set any blocking WRT SeaMonkey here, though.

Comment 3

9 years ago
Bug 588291 dealt with the same issue for Fennec.  Moving SeaMonkey before Firefox in the APP_DETECT list in apps/amo/__init__.py would most likely fix the problem (CCing some relevant people just to be sure, though).
Reporter

Comment 4

9 years ago
(In reply to comment #3)
> Bug 588291 dealt with the same issue for Fennec.  Moving SeaMonkey before
> Firefox in the APP_DETECT list in apps/amo/__init__.py would most likely fix
> the problem (CCing some relevant people just to be sure, though).

More precisely, I think Firefox needs to be moved to the end of the list. Thunderbird could theoretically turn on this compat flag too, I guess.
I think that will fix it too
Assignee

Comment 6

9 years ago
I'll get a patch up within ~24 hours for just that, and hope that it can be accepted by next rollout.
(In reply to comment #6)
> I'll get a patch up within ~24 hours for just that, and hope that it can be
> accepted by next rollout.

It's too late for this Thursday, but we can get it in the next one.  Like I said on IRC, don't forget to add/adjust the unit tests.

Comment 8

9 years ago
ping?
Assignee

Comment 9

9 years ago
Fell through my cracks, sorry.
Assignee: nobody → bugspam.Callek
Assignee

Comment 10

9 years ago
Posted patch v1Splinter Review
Ok, I was unable to run the test since I don't have django installed and not certain the best way to install that in my MozBuild python. so I'm hoping this looks good as is.

I opted for Firefox at the end of the list now, based on prior conversations both in IRC and this bug.
Attachment #481414 - Flags: review?(clouserw)
Attachment #481414 - Flags: review?(clouserw) → review-
r- on the patch because you are missing a closing parenthesis, but I fixed it when I committed it:

http://github.com/jbalogh/zamboni/commit/31d65bbd30232dbdd36c7153fe55ae2cf759d573
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 5.12.1
Assignee

Comment 12

9 years ago
o wth stupid typos, but thanks for landing it.
Verified FIXED using:

Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101007 Firefox/4.0b8pre SeaMonkey/2.1b1pre

On prod, I get taken to /firefox, and on preview, I land on https://preview.addons.mozilla.org/en-US/seamonkey/
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.