1215125 - the admin switches locales between refreshes

Status: RESOLVED FIXED

(Input :: General, defect)

Description

[Will Kahn-Greene [:willkg] ET needinfo? me]

Bear with me, this is weird. It's probably Fringe-worthy weird.

If you go into the admin and refresh any of the admin pages a few times, it'll switch locales: text that's been translated, the way dates are formatted, etc.

I can only see this in production--not stage or locally. It's likely because production has enough traffic that it's seeing requests from non-english locales. It's possible that I could figure out how to reproduce it given enough time.

I've never seen this before, so I'm guessing it's related to either upgrading to Django 1.8 and/or the changes we made when we dropped jingo and tower.

Since this only affects the admin, I think we're "ok", but it's definitely fishy and should probably be looked into.

Comment 1

[Osmose [:osmose, :mkelly]]

MDN ran into this same issue and solved it be reordering middleware (bug 1237661)

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

Grabbing this because I'm going to look into it next week because it's irritating.

I was thinking first thing I could do would be to create an admin view that shows me all the relevant variable values for the request, user and session and whatever else.

Mike suggested that the problem could be that the locale middleware is ignoring admin/ views when it goes to set the locale and because it's ignoring them, nothing gets set, so then the admin uses the language set by the last request. That's definitely something to look into.

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

I can reproduce this on -stage now.

STR:

1. in one browser, log in and go to /admin/
2. in another fresh browser, go to /fr/ a bunch of times
3. in the first browser, refresh the admin

This will turn the admin french (assuming no one else is touching -stage at the time). I can switch to other languages, too--this isn't a problem with just fr.

I can't reproduce it locally using "./manage.py runserver" or "./manage.py runserver_plus", but if I fix the totally broken fjord/wsgi.py file, I can reproduce it using "gunicorn fjord.wsgi".

Now that I can reproduce it locally, I'll investigate Mike's theory.

Comment 4

[Will Kahn-Greene [:willkg] ET needinfo? me]

I'm pretty sure I figured it out. Our prefixer returns '' for locale for the /admin/ pages. Our locale aware middleware calls translation.activate(prefixer.locale) which is '' for the /admin/.

Django 1.8 picked up this fix:

https://github.com/django/django/commit/543df07720181fe23737ba14f1a261ff6f37f49c

So then prefixer.locale is '', our locale-aware middleware calls translation.activate('') and now that does nothing which causes /admin/ to be rendered with the language of the previously handled request for that thread.

In a PR: https://github.com/mozilla/fjord/pull/732

Comment 5

[Will Kahn-Greene [:willkg] ET needinfo? me]

Landed in https://github.com/mozilla/fjord/commit/5109f96c12a86f38123c59c6b05d73a0832266b6

I want to push this to -stage today, verify it works and then push it to -prod. I'll coordinate with Mike Kelly to do this.

Comment 6

[Will Kahn-Greene [:willkg] ET needinfo? me]

Tested it on -stage and it was super duper. Yay!

Comment 7

[Will Kahn-Greene [:willkg] ET needinfo? me]

I'm going to assume this has been pushed to -prod by now. Closing this out.