Closed Bug 594578 Opened 10 years ago Closed 10 years ago

Deal with SeaMonkey with Firefox compatibility declared in its UA string

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
5.12.1

People

(Reporter: davemgarrett, Assigned: Callek)

References

Details

Attachments

(1 file)

Filed per bug 591327 comment 15.
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.
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
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.
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).
(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
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.
ping?
Fell through my cracks, sorry.
Assignee: nobody → bugspam.Callek
Attached 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
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 5.12.1
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.