Created attachment 612127 [details] screenshot.png User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20100101 Firefox/12.0 Build ID: 20120328051619 Steps to reproduce: Running WebQA QMO automation which failed logging in Actual results: Login Username and Password fields remain on the homepage but the content you should see when you login appears. User is getting logged in corrently. Expected results: Avatar, username and Logout options should appear instead.
Confirmed; thanks for the bug, Glenn. Sorry it took so long :-(
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
It looks like this works for me in Chrome Canary but breaks in the latest trunk build of Firefox.
This is still broken as of today in Firefox 14 Beta. This does cause user confusion; had to coach someone through it today. It's not at all obvious that going to another page (Team, Community, etc.) will show you as logged in.
We've got to fix this -- new users who make their way to IRC are telling us that signup is broken, when in fact (at least in the couple of cases I've also recently coached), they've "just" hit this bug. Craig, any ideas?
Severity: major → critical
It seems to just be aggressive caching due to SSL. Upon logging in you're sent back to the page you were just on, but it doesn't actually reload that page. You have to force-reload it, or else visit some other uncached page so the login area updates with fresh HTML. I'm not sure how to fix it.
Why not force pages to expire immediately?
I think this is fixed now. Works for me, anyway, although the solution may or may not be ideal. I added this to the Apache config for quality.mozilla.org: ExpiresByType text/html "now" By default, our load balancers will cache based on whatever headers they receive from the origin servers. They obey Vary headers and the like, so this is almost never a problem. If the origin sends no headers (as Wordpress does by default), the LBs will cache for their own internal TTL (10min, usually). This is a little odd... you might expect that if no cache headers exist in a response, that the response should not be cached. In fact quite often an omission of headers is not indicative of intent... *usually* it won't hurt anything to cache the page for a short while, and so that's what our LBs do. In this case the contents of the page actually are dynamic, and this assumption breaks down. Usually one would want to deal with this by sending a proper Vary: header. I don't know if that's feasible in this situation- it would likely require some Wordpress-fu that I don't possess. The other option is to simply not cache such pages at all... that's what I have done here. I think this is probably as good as we're likely to do under the circumstances. A proper Vary header might just result in a huge amount of new cache objects (one per user, since the content contains the username), which basically destroys the value of the cache. I'm content to leave this as-is indefinitely.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
verified fixed https://quality.mozilla.org/
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.