Created attachment 8363370 [details] logcat_20140121.txt Description: After logging in to a gmail account to import contacts the user cannot log out again to import contacts from a different account. Repro Steps: 1) Update a Buri to BuildID: 20140121004137 2) Open "Contacts" -> Settings 3) Select Import Contacts -> Gmail 4) Select all contacts and then import 5) Select gmail again -> Deselect all contacts and update. 6) Select gmail again Actual: The contact selection page reappears, skipping the log in page. Expected: The account sign in page appears, allowing the user to quickly log in to the same account or enter the details for a different gmail account. 1.3 Environmental Variables: Device: Buri 1.3 MOZ BuildID: 20140121004137 Gaia: 47049555282a9a01fb60d1e1421b57e2810c96f5 Gecko: 6f7dfe36ab6c Version: 28.0a2 Firmware Version: v1.2-device.cfg This does not happen in 1.2 and does not happen when using a hotmail account. Notes: Newer version of previously resolved bug: https://bugzilla.mozilla.org/show_bug.cgi?id=861290 Repro frequency: 100% Link to failed test case: https://moztrap.mozilla.org/manage/case/7069/ See attached: logcat
Does NOT occur o 1.2 Environmental Variables: Device: Buri 1.2 MOZ BuildID: 20140121004053 Gaia: 539a25e1887b902b8b25038c547048e691bd97f6 Gecko: c9f305c1d9a7 Version: 26.0 Firmware Version: v1.2-device.cfg
status-b2g-v1.2: --- → unaffected
Jose Manuel, cannot find the bug, but I'm pretty sure this is a duplicate of one caused by a security bug isnt?
blocking-b2g: --- → 1.3?
Keywords: regression, regressionwindow-wanted
Ah I didn't read the first comment completely. If Hotmail isn't failing, then it's not using cookies to keep the session open.
This issue started reproducing on the 12/06/13 1.3 build. - Works - Device: Buri v1.3 MOZ RIL BuildID: 20131205040201 Gaia: 1dd0e5c644b4c677a4e8fa02e50d52136db489d9 Gecko: 725c36b5de1a Version: 28.0a1 Firmware Version: V1.2-device.cfg - Broken - Device: Buri v1.3 MOZ RIL BuildID: 20131206040203 Gaia: 8fca2ca67e8a6022fe6ed8cb576e5d59dfb5237f Gecko: 1401e4b394ad Version: 28.0a1 Firmware Version: V1.2-device.cfg
Jose - Can you investigate this, since you fixed a similar bug to this with Facebook?
blocking-b2g: 1.3? → 1.3+
oh, yeah taking it as I know how to fix it
Assignee: nobody → jmcf
Created attachment 8367346 [details] 15806.html Logout is now done through window.open and continue param supported by Google. As the process now is longer the status is shown just right after logout. Pending logouts if user is offline are no longer supported, as opening windows would disturb the user.
Attachment #8367346 - Flags: review?(francisco.jordano)
I CAN HAZ tests please?
Still weird what I can see when trying this. Did a make reset-gaia and still I have the window for more than 15 seconds till it closes: https://drive.google.com/file/d/0B3RfQh7fuZjAOEx5Z2NGQ0E4Mm8/edit?usp=sharing To me, a user could consider it as a bug, I was thinking in other possible solutions, like loading that logout url (and all their crazy redirections) into an iframe, will that work? Do you think is possible, also unit tests are complicated for this?
(In reply to Francisco Jordano [:arcturus] from comment #10) > Still weird what I can see when trying this. > > Did a make reset-gaia and still I have the window for more than 15 seconds > till it closes: > > https://drive.google.com/file/d/0B3RfQh7fuZjAOEx5Z2NGQ0E4Mm8/edit?usp=sharing > > To me, a user could consider it as a bug, I was thinking in other possible > solutions, like loading that logout url (and all their crazy redirections) > into an iframe, will that work? > unfortunately not, that URL is not allowed to be loaded from an iframe :( The alternative solution would be to close the window after 5 or 6 seconds but that would not guarentee the logout is done 100% of the times. > Do you think is possible, also unit tests are complicated for this?
Comment on attachment 8367346 [details] 15806.html Unfortunately this window staying for 15 seconds is not a valid solution. It's not a problem with the code, but a problem with the service, so we should try to resolve this in a different way. Please see bug 966216
Attachment #8367346 - Flags: review?(francisco.jordano) → review-
PM reviewed and stays a blocker
Can we get ETA to fix this bug? Thank you.
We cannot properly fix this bug until bug 966216 is fixed. And that bug has not even been nominated and input requested from :sicking is not yet available.
New idea to fix this. When we click the Gmail import button, if we have an access_token, we go to the logout page first and then we go to the oauth page. If we don't have an access_token, we go directly to the oauth page. I'm proposing this because the "import from two gmail accounts" scenario looks pretty rare. With that UX, the single account scenario works like now. And the two account scenario is delayed but I believe this is an acceptable fix.
OK, other idea. Instead of logging out, we just always display the Google approval window when we click on the Gmail import button. You can try this workflow with this ugly patch: https://gist.github.com/Rik/8828236. What do you think Jose?
Created attachment 8371366 [details] 16031.html I have implemented the proposal from Anthony (thanks). I think it is not the best situation for the user but it solves the problem. I would ask someone from product to also test it and decide it is an acceptable solution.
This is not implementing what I proposed and not resolving the bug. With your patch, as long as the token is valid, you won't get prompted the Google page.
nope as the token is removed once you import contacts.
Ah okay, I only tested by cancelling once on the screen with the list of gmail contacts. Sorry for that.
(In reply to Jose M. Cantera from comment #18) > Created attachment 8371366 [details] > 16031.html > > I have implemented the proposal from Anthony (thanks). I think it is not the > best situation for the user but it solves the problem. I would ask someone > from product to also test it and decide it is an acceptable solution. Hi, As far I can see, the fix consists in always showing "grant permissions" window from which users are able to change the account, not the best experience for users but at least the chance of changing the account is there, better than nothing!. ni to UX and Product to confirm if this behavior would be acceptable for v1.3. Thanks!
Attachment #8371366 - Flags: feedback?(noef) → feedback+
Comment on attachment 8371366 [details] 16031.html It does work for me, not the perfect solution but we give the user the chance of login out and login with a different user. I'm ok with this for 1.3 timeframe, but would love to find a better solution as we used to have before. Thanks Jose and Anthony!
Attachment #8371366 - Flags: review?(francisco.jordano) → review+
From a UX PoV the fix is not absolutely ideal, but I know Jose has pushed this as far as he can in the time he has allotted, and therefore it is acceptable for the 1.3 timeframe. I have two requests: 1) Can we get the new permissions screen within the page so that the user does not have to scroll right->left in order to access the 'accept' CTA? 2) Is it possible to do anything about the transitions for 1.3? If not, can we look at them asap. 2) As Francisco says in comment 23, can we see this as an interim solution for 1.3 and put the investigation of a more robust one on the roadmap for 1.4?
(In reply to ayman maat :maat from comment #24) > From a UX PoV the fix is not absolutely ideal, but I know Jose has pushed > this as far as he can in the time he has allotted, and therefore it is > acceptable for the 1.3 timeframe. > > I have two requests: > > 1) Can we get the new permissions screen within the page so that the user > does not have to scroll right->left in order to access the 'accept' CTA? I'm afraid we cannot do anything as that page is generated by Google. > 2) Is it possible to do anything about the transitions for 1.3? If not, can > we look at them asap. Can you be more specific? > 2) As Francisco says in comment 23, can we see this as an interim solution > for 1.3 and put the investigation of a more robust one on the roadmap for > 1.4? Yes sure
Best we can do for now in the time available - and it addresses the core issue. Fine with the proposal.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Uplifted d1e46d3b273c9926e87e00ec42ff115a2e1f4b7b to: v1.3: 1abf8760325f411779e9bccd6da8f9ece09ace14
status-b2g-v1.3: affected → fixed
status-b2g-v1.3T: --- → fixed
status-b2g-v1.4: --- → fixed
You need to log in before you can comment on or make changes to this bug.