Closed Bug 962377 Opened 10 years ago Closed 10 years ago

[B2G][Contacts] User is unable to sign out of a gmail account and in to another after importing contacts.

Categories

(Firefox OS Graveyard :: Gaia::Contacts, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.3+, b2g-v1.2 unaffected, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 fixed)

RESOLVED FIXED
1.4 S1 (14feb)
blocking-b2g 1.3+
Tracking Status
b2g-v1.2 --- unaffected
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed

People

(Reporter: lmauritson, Assigned: jmcf)

References

Details

(Keywords: regression, Whiteboard: burirun1.3-2)

Attachments

(2 files, 1 obsolete file)

Attached file 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
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?
I think Francisco is referring to bug 956893. But this is not a duplicate. It's just the same problem, at a different service. And if Live uses cookies also to keep the session, it will fail in the same way. I think you can take the same solution here that was taken there (don't use XHR to do the logout).
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.
QA Contact: mvaughan
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+
Flags: needinfo?(jmcf)
oh, yeah taking it as I know how to fix it
Assignee: nobody → jmcf
Flags: needinfo?(jmcf)
Attached file 15806.html (obsolete) —
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)
Target Milestone: --- → 1.3 C3/1.4 S3(31jan)
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?
Flags: needinfo?(jmcf)
Attached file 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.
Attachment #8367346 - Attachment is obsolete: true
Attachment #8371366 - Flags: review?(francisco.jordano)
Attachment #8371366 - Flags: feedback?(noef)
Flags: needinfo?(jmcf)
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!
Flags: needinfo?(wmathanaraj)
Flags: needinfo?(aymanmaat)
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?
Flags: needinfo?(aymanmaat)
Target Milestone: 1.3 C3/1.4 S3(31jan) → 1.4 S1 (14feb)
(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.
Flags: needinfo?(wmathanaraj)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Uplifted d1e46d3b273c9926e87e00ec42ff115a2e1f4b7b to:
v1.3: 1abf8760325f411779e9bccd6da8f9ece09ace14
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: