Closed Bug 890488 Opened 11 years ago Closed 9 years ago

[stage] Redirecting on site homepage after normal user workflow

Categories

(Participation Infrastructure :: Phonebook, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: AndreiH, Unassigned)

References

()

Details

(Whiteboard: [Triage 2015-04-17][fromAutomation][stage][prod])

This is an intermittent anomaly that I am seeing in the tests results/fails and it can even be reproduced manually.
The user is redirected to the homepage first (showing him signed out) when going through the site. (eg: clicking on mozillians logo; filtering users by users current city/region/country)

Here is a screencast of me managing to replicate it manually:
http://screencast.com/t/gYkAj2YIS
Here is a screencast of the failing test that is clicking to filter results by city:
http://screencast.com/t/oRfIkW5jgZPn
Whiteboard: [fromAutomation]
I can see this behaviour on prod aswell
Whiteboard: [fromAutomation] → [fromAutomation][stage][prod]
I have noticed this behavior as well. While it's not ideal, the user does get redirected to the proper view.

Is this causing 1) tests to fail or 2) problems with our automation? I'm trying to understand the impact of the current behavior.
Flags: needinfo?(andrei.hutusoru)
(In reply to William Reynolds [:williamr] from comment #2)
> Is this causing 1) tests to fail or 2) problems with our automation? I'm
> trying to understand the impact of the current behavior.

Yes, this is causing tests to intermittently fail.
I have replicated this. I have only seen it when clicking on the Mozillians logo; I tried and was unable to replicate it clicking on only other links.

It is not necessary to browse. If you simply click on the mozillians logo repeatedly, it will happen sooner or later (for me, within ~2 minutes or so).

I have further noticed that the improper redirect coincides with a cookie being set. You can replicate this yourself: Find and delete the anoncsrf cookie for mozillians.org. It will stay deleted until such time as the improper redirect occurs, and then it will appear.

Here's the output from the Network panel of the browser console when the improper redirect occurs:

http://pastebin.com/EHtENB5c

Here's the output when it doesn't occur:

http://pastebin.com/sN1JA2HU

The differences are in the first ~18 lines of code.

:giorgos, do you think this may relate to stronghold?
Flags: needinfo?(giorgos)
Here is an example on a test that failed https://saucelabs.com/jobs/f583f3a6e6b14a729cd9f7bed0291e46#
After clicking on users profile region, the user is first redirected to the hone_page
This is the test: https://github.com/mozilla/mozillians-tests/blob/master/tests/test_profile.py#L182
Flags: needinfo?(andrei.hutusoru)
I'm able to reproduce it as well. I originally thought that this was caused by my privacy addons in Firefox :)

It seems that this is a known unresolved issue of (django) browserid. 

https://github.com/mozilla/django-browserid/issues/152

Tried downgrading to django-browserid v0.6 and upgrading to HEAD without luck.

Maybe mkelly can give us more insight?
Flags: needinfo?(giorgos) → needinfo?(mkelly)
I've been looking at what happens in the browser when the redirect to logout happens, and all I can tell is that it seems that the request prior to the auto-redirect to logout doesn't actually finish; the connection log just seems to suddenly redirect me to the logout page.

giorgos: Do you see this on a local copy of Mozillians? If so, can you replace the logout redirect in the browserid.js file with a console.log statement and see if you can still replicate?

If it happens locally even when that line is gone, then it's not django-browserid's code that's doing the redirect, and something else is happening. If it doesn't happen when that line's gone, then I'd like to check if the #browserid-info <div> is in the page's source when it hits that line and if it has the user's email in it.

Let me know if you can't do this locally and I can set up Mozillians myself and try.
Flags: needinfo?(mkelly)
- Yes I can reproduce it locally.

- Replaced 'logout' with a console.log and I got nothing, like it's not called. This makes some sense, since the persona creds are not invalidated (navigator.id.logout is not called if I understand correctly), because when you land onto the 'logged out' view you get automatically re-logged in.

- I placed the browserid_js() template context processor inside an 'if', to appear only when the user is logged out. I can't reproduce anymore, so it looks that's somehow related to browserid.js or include.js.
Tried to reproduce without success. Also browserid is now updated to 0.10.1
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Whiteboard: [fromAutomation][stage][prod] → [Triage 2015-04-17][fromAutomation][stage][prod]
You need to log in before you can comment on or make changes to this bug.