Closed
Bug 1101444
Opened 10 years ago
Closed 10 years ago
[Loop] For each invalid inserted verification code, Device receives a valid verification code.
Categories
(Firefox OS Graveyard :: Gaia::Loop, defect)
Tracking
(blocking-b2g:2.0+, firefox34 wontfix, firefox35 wontfix, firefox36 fixed, b2g-v2.0 verified, b2g-v2.0M verified, b2g-v2.1 verified, b2g-v2.2 verified)
People
(Reporter: lolimartinezcr, Assigned: ferjm)
References
Details
(Whiteboard: [mobile app])
Attachments
(2 files, 2 obsolete files)
(deleted),
patch
|
spenrose
:
review+
bajaj
:
approval-mozilla-b2g32+
bajaj
:
approval-mozilla-b2g34+
|
Details | Diff | Splinter Review |
(deleted),
video/mp4
|
Details |
flame
user
v2.0
188based
Gecko-de95811
Gaia-1ede266
Loop versión: 1.1, 38eadf0
STRs:
1. In device A, clicks Loop application.
2. In device A, clicks "Use Phone Number" button.
3. In device A, clicks "Or add your phone number" link
4. Write a phone number (different to phone number in SIM card) and clicks "Share" button -> Device B (with phone number inserted) receives SMS with autentication code.
5. In device A, inserts an invalid autentication code and clicks "Verify" button.
Actual result:
For each invalid inserted verification code, Device B receives a SMS with a valid verification code. (See attached video: http://youtu.be/FbufNSfRm6w)
Expected result:
When user inserts invalid verification code, in device A should shown a warning and not send other autentication code.
Comment 1•10 years ago
|
||
Fernando, as far as I know, the MSISDN server should not send a new verification code when you fails in entering the code. I would expect that it notifies about the fault and, only, when the user taps on "Resend" button a new verification button would be sent.
Wdyt? Has there been any change in the MSISDN server lately?
Flags: needinfo?(ferjmoreno)
Assignee | ||
Comment 2•10 years ago
|
||
Yes, this doesn't seem to be working fine. AFAIK no changes has been done that may have caused this. I'll take a look as soon as I can.
Flags: needinfo?(ferjmoreno)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → ferjmoreno
Comment 3•10 years ago
|
||
[Blocking Requested - why for this release]: Important failure and Fernando points that seems to be a platform issue.
The MSISDN server should not send a new verification code when you fails in entering the code. I would expect that it notifies about the fault and, only, when the user taps on "Resend" button a new verification button would be sent.
blocking-b2g: --- → 2.0?
Assignee | ||
Comment 4•10 years ago
|
||
This patch fixes the issue. I am working on the tests for this now.
Assignee | ||
Comment 5•10 years ago
|
||
And now with the test.
I enabled the tests in TBPL disabling the MobileIdentityManger test and triggered a try run https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=f1ddb9f62f96
I still need to enable the tests for MobileIdentityManager in TBPL, but that's another story that should happen at bug 1073595
Attachment #8529017 -
Attachment is obsolete: true
Assignee | ||
Comment 6•10 years ago
|
||
Sam, could you take a look at this patch, please?
It looks like a lot of changes, but it is basically moving blocks of codes from one place to another. The reason of this issue was that we were restarting the verification process (MobileIdentityVerificationFlow.doVerification) every time the user entered an invalid verification code. Now we only do that when the verification timeout expires. If the verification code entered by the user is wrong we just restart part of the verification flow (MobileIdentityVerificationFlow._doVerification).
As I mentioned in the comment above, I also added a test for this and enabled the tests in TBPL. It seems again like a lot of changes in the tests but what I did was moving the common part of what we had in test_mobileid_manager.js to head.js so we can use the mock helpers in the new test as well.
Thanks!
Attachment #8529159 -
Attachment is obsolete: true
Attachment #8529168 -
Flags: review?(spenrose)
Comment 7•10 years ago
|
||
Comment on attachment 8529168 [details] [diff] [review]
v1
Hi Fernando --
Thanks for the explanation of the patch. It makes sense, reads clearly, and builds cleanly. I have not run the xpcshell tests.
Attachment #8529168 -
Flags: review?(spenrose) → review+
Assignee | ||
Comment 8•10 years ago
|
||
Comment 9•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 10•10 years ago
|
||
Tested and working in:
flame
user
master
188based
Gecko-8d8a729
Gaia-f20b72c
Loop version: master, fe0b50f
Will it be resolved in 2.0? Pending 2.0
Comment 11•10 years ago
|
||
Hi Wesly,
as you are reviewing 2.0 nominations, could you please consider also this bug? It's quite important for Loop application as it's using registration via Mobile ID.
Flags: needinfo?(wehuang)
Comment 12•10 years ago
|
||
Fernando, can you please ask for the approval for b2g32 and b2g34? This is an important bug for loop Mobile client
Flags: needinfo?(ferjmoreno)
Comment 13•10 years ago
|
||
Sorry for late, Maria!
[Triage] tag due to the importance of Loop, also a fix is available.
blocking-b2g: 2.0? → 2.0+
Flags: needinfo?(wehuang)
Assignee | ||
Comment 14•10 years ago
|
||
Comment on attachment 8529168 [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 #): MobileID
User impact if declined: Wrong behavior and UX of the verification process that causes unnecessary costs to Mozilla and potential costs to the user.
Testing completed: Manual tests and unit tests added and running on TBPL.
Risk to taking this patch (and alternatives if risky): Low risk.
String or UUID changes made by this patch: None.
Flags: needinfo?(ferjmoreno)
Attachment #8529168 -
Flags: approval-mozilla-b2g34?
Attachment #8529168 -
Flags: approval-mozilla-b2g32?
Comment 15•10 years ago
|
||
Comment on attachment 8529168 [details] [diff] [review]
v1
Apologies on the late approval here, I agree on taking this.
Loli, Can you please help with verification once this lands on 2.0 branach.
Attachment #8529168 -
Flags: approval-mozilla-b2g34?
Attachment #8529168 -
Flags: approval-mozilla-b2g34+
Attachment #8529168 -
Flags: approval-mozilla-b2g32?
Attachment #8529168 -
Flags: approval-mozilla-b2g32+
Comment 16•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/a4714522912d
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/fcdb03d3674b
status-b2g-v2.0:
--- → fixed
status-b2g-v2.1:
--- → fixed
status-b2g-v2.2:
--- → fixed
status-firefox34:
--- → wontfix
status-firefox35:
--- → wontfix
status-firefox36:
--- → fixed
Flags: in-testsuite+
Target Milestone: --- → 2.2 S1 (5dec)
Reporter | ||
Comment 17•10 years ago
|
||
(In reply to bhavana bajaj [:bajaj] from comment #15)
> Comment on attachment 8529168 [details] [diff] [review]
> v1
>
> Apologies on the late approval here, I agree on taking this.
>
> Loli, Can you please help with verification once this lands on 2.0 branach.
Hi Ryan, yes I will help with verification!
Comment 18•10 years ago
|
||
status-b2g-v2.0M:
--- → fixed
Comment 19•10 years ago
|
||
This bug has been successfully verified on woodduck 2.0 and Flame v2.0&2.1&2.2.
See attachment: verified_v2.1.mp4.
Reproduce rate: 0/5.
STR:
1. In device A, click Loop application.
2. In device A, click "Use Phone Number" button.
3. In device A, click "Or add your phone number" link(on flame,user can direct to input number)
4. Write a phone number (different to phone number in SIM card) and click "Share" button -> Device B (with phone number inserted) receives SMS with autentication code.
5. In device A, insert an invalid autentication code and clicks "Verify" button.
**When user insert invalid verification code, device A shows the warning with the red input box flashing, and not send other autentication code.
Flame 2.2 build:
Gaia-Rev f5e481d4caf9ffa561720a6fc9cf521a28bd8439
Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/bb8d6034f5f2
Build-ID 20150111010223
Version 37.0a1
Device-Name flame
FW-Release 4.4.2
FW-Incremental eng.cltbld.20150111.043244
FW-Date Sun Jan 11 04:32:55 EST 2015
Bootloader L1TC000118D0
Flame 2.1 build:
ia-Rev 64db236bea9a0510567ab7ced2f2b4688737123c
Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/273f24a1d1fe
Build-ID 20150111001202
Version 34.0
Device-Name flame
FW-Release 4.4.2
FW-Incremental eng.cltbld.20150111.035122
FW-Date Sun Jan 11 03:51:33 EST 2015
Bootloader L1TC000118D0
Flame 2.0 build:
Gaia-Rev 31d6c9422cd0a8213df9f96019c9ab7168ec3ab3
Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a05a5378cb1f
Build-ID 20150111000203
Version 32.0
Device-Name flame
FW-Release 4.4.2
FW-Incremental eng.cltbld.20150111.034429
FW-Date Sun Jan 11 03:44:40 EST 2015
Bootloader L1TC000118D0
Woodduck 2.0 build:
aia-Rev 7e55f20bc0f82397207cac6b5b477948652da62c
Gecko-Rev 5e2c8611f0705e5ee656e3bfad8e8ee9bde228fe
Build-ID 20150112050313
Version 32.0
Device-Name jrdhz72_w_ff
FW-Release 4.4.2
FW-Incremental 1421010380
FW-Date Mon Jan 12 05:06:48 CST 2015
Comment 20•10 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•