Closed Bug 1076708 Opened 5 years ago Closed 5 years ago
[Loop] Close the verification code windows cause the app trying to authenticate infinitely
Device: Flame kk (v180) Loop version: d1e6002 Gaia/Gecko: 9725d18/b7ca55f STR 1. Open Loop app 2. Click on "Use Phone Number" option 3. Click on "Or add your phone number" link 4. Introduce an invalid phone number (i.e +34600000005). 5. On the verification code window introduce an invalid code (i.e 555555) and click on verify. 6. Now close the verification code window clicking on the "X" ACTUAL RESULT The app come back to the main window with the message "Authenticating". You have to kill the app.
Fernando, can you have a look at it?
Hardware: x86 → ARM
Assignee: nobody → ferjmoreno
We were not rejecting the promises and cleaning up properly when the user cancelled the verification prompt.
Comment on attachment 8500993 [details] [diff] [review] v1 The patch reads fine. Without bug 1073595 I did not run the tests. Thanks Fernando.
Attachment #8500993 - Flags: review?(spenrose) → review+
Re-checking this issue, you do not need to introduce an invalid phone number or an wrong pin code to reproduce the fault, just entering a different phone number to the one included in the SIM and pressing "X" in the verification window the bug can be reproduced STR 1. Open Loop app 2. Click on "Use Phone Number" option 3. Click on "Or add your phone number" link 4. Introduce a phone number different to the one included in the SIM 5. On the verification code window click on the "X" ACTUAL RESULT The app come back to the main window with the message "Authenticating". You have to kill the app.
[Blocking Requested - why for this release]: According to the new STR in comment 6, the severity of this bug is higher and it's important we can have this fix in 2.0 too to avoid issues with the Mobile ID verification in Loop
Severity: normal → major
blocking-b2g: --- → 2.0?
Whiteboard: [platform][smoke-tef] → [platform][smoke-tef][blocking]
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S6 (10oct)
Verified fixed on Flame 2.2 (319mb/full flash) Actual result: User is returned to the main window. Device: Flame 2.2 BuildID: 20141012040203 Gaia: 717ad4e8b7fc10ab8248500d00ba5ba0977fa8ab Gecko: 44168a7af20d Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 35.0a1 (2.2) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Awaiting uplift for 2.1 Leaving verifyme keyword for 2.1. verification.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Chris, I am not sure if we have this included by default on 2.0? Can you or someone from product confirm? If we will include it in 2.0 then I think we should block on this one. Thanks.
It's happening second time closing the verification code window clicking on the "X". Device: Flame Gecko-86f7a81.Gaia-21fc294 and FireE: firee-kk-v2.0-SW2E2-3 Loop version: ba8a3cb
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
-> Resolved: it's already resolved but not uplifted to 2.0
Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
Resolution: --- → FIXED
Bhavana, looks like an uplift approval is needed here.
(In reply to Wayne Chang [:wchang] from comment #11) > Chris, > > I am not sure if we have this included by default on 2.0? Can you or someone > from product confirm? yes it is. > > If we will include it in 2.0 then I think we should block on this one. > Thanks. Hence blocking here and approving uplift.
blocking-b2g: 2.0? → 2.0+
Fernando, can you request an approval for uplift on b2g32/b2g34 ?
(setting ni(ferjm) just in case)
Comment on attachment 8500993 [details] [diff] [review] v1 NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] Bug caused by (feature/regressing bug #): Mobile ID User impact if declined: Bad UX. If the user closes the Mobile ID dialog while on the verification code screen, the Mobile ID API won't return any result and may leave the caller app in a blocked status. That's the current case for Loop. Testing completed: QA verified and unit tests added. Risk to taking this patch (and alternatives if risky): Very low. String or UUID changes made by this patch: None.
Attachment #8500993 - Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
Hi Bhavana, we need the approval to uplift the patch to 2.0... can you help us with this? Thanks a lot!!
Attachment #8500993 - Flags: approval-mozilla-b2g32? → approval-mozilla-b2g32+
Tested with Loop v. 1.1 (59294fd) and works fine
Status: RESOLVED → VERIFIED
Verified on FireE, firee-kk-v2.0-SW2E5-4, loop version, 1.1: cc87bd0
This issue has been verified successfully on Flame2.0&2.1,Woodduck2.0. Reproducing rate: 0/5 See attachment: Verify_Flame_Loop.mp4 Flame2.0 build version: Gaia-Rev 856863962362030174bae4e03d59c3ebbc182473 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/2d0860bd0225 Build-ID 20141210000202 Version 32.0 Flame2.1 build version: Gaia-Rev c226db212db4d824c09617cd6dc407b2d4258d9b Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/cf8bebfa4703 Build-ID 20141210001201 Version 34.0 Woodduck2.0 build version: Gaia-Rev ead3b72a84512750bc5faff4e9e8faa1715c0d05 Gecko-Rev 8d40d6480ee0e628b0f7655dcd6ff79a2f2fbcfc Build-ID 20141211050313 Version 32.0
You need to log in before you can comment on or make changes to this bug.