Closed Bug 1045581 Opened 6 years ago Closed 6 years ago

[MobileID] The Mobile ID flow can't be completed with a manually inserted phone number


(Firefox OS Graveyard :: Gaia::System, defect, P1)

Gonk (Firefox OS)


(blocking-b2g:2.0+, firefox33 wontfix, firefox34 fixed, firefox35 fixed, b2g-v2.0 verified, b2g-v2.0M verified, b2g-v2.1 verified, b2g-v2.2 verified)

2.1 S4 (12sep)
blocking-b2g 2.0+
Tracking Status
firefox33 --- wontfix
firefox34 --- fixed
firefox35 --- fixed
b2g-v2.0 --- verified
b2g-v2.0M --- verified
b2g-v2.1 --- verified
b2g-v2.2 --- verified


(Reporter: javier.deprado, Assigned: ferjm)



(Whiteboard: ft:Loop [blocking][platform])


(2 files, 1 obsolete file)

Device: FireE
Loop version: 08b040a
Build: flame_light-JB.user.master.B-56.Gecko-cc3c2e4.Gaia-8dd303f

1.- Login using Phone Number
2.- Choose "add your phone number"
3.- Don't put any prefix, and fill the number field.
4.- Push "share" button.

Loop remains permanently trying to connect.

Some message should be displayed. (or not be able to leave the field blank)
Blocks: 1036490
Component: Gaia::Loop → Gaia::System
I am reproducing this issue even inserting the CC. 
This happens if I've never registered with that number with the Mobile Identity API. Once I am registered automatically (using SIM1 icon) if I log out and try to register again manually (entering the MSISDN) I am able to make the registration.
After doing some tests this seems to be something related with Gecko or MobileID server, but I would like to get Fernando's feedback first.

When trying to validate an external phone number, choosing the CC/MSISDN (this is sent to Gecko from System/MobileID, so I think the problem is not here), I receive the SMS in my phone number with the verification code.
However, MobileID flow is not moving forward to the next step, and this could be:
- Code 204 is not arriving properly to FirefoxOS device
- Verification promise is not working as expected
The former one seems to be the one to investigate, due to I can see the timeout expiration after tapping on the first button of the flow.
Fernando, I hope it helps!
Flags: needinfo?(ferjmoreno)
I can't reproduce this issue.

With an inserted SIM, a default CC is set after bug 1046736, so you can't leave the CC field empty. With no inserted SIM, leaving the CC empty and clicking next makes the phone number field "dance in red" and doesn't allow me to progress with the flow and the "INVALID_PHONE_NUMBER" is shown in the logcat, which seems like the expected behavior. Adding the CC in the phone number field gives the same error.
Closed: 6 years ago
Flags: needinfo?(ferjmoreno)
Resolution: --- → WORKSFORME
Actually, this might be a valid issue. We are adding a default +7 while we shouldn't:

Gecko  I  1409556223568	MobileId	DEBUG	startFlow result {"phoneNumber":"638677837","prefix":"+7","mcc":"289","serviceId":null}
Gecko  I  1409556223602	MobileId	ERROR	UI error INVALID_PHONE_NUMBER

After getting this error, the next retry with the appropriate CC doesn't work as expected. The flow doesn't progress to the verification code screen.
Assignee: nobody → ferjmoreno
Resolution: WORKSFORME → ---
Summary: [Loop] Trying to login in Loop with SIM introduced directly by user, if you don`t put the country prefix, Loop remains connecting. → [MobileID] The Mobile ID flow can't be completed after a failed try with a manually inserted phone number
Summary: [MobileID] The Mobile ID flow can't be completed after a failed try with a manually inserted phone number → [MobileID] The Mobile ID flow can't be completed with a manually inserted phone number
[Blocking Requested - why for this release]:

[Blocking Requested - why for this release]: Nominating because right now it's not possible to make the manual Mobile ID registration (inserting manually the number) with and without CC. Although the SMS with the PIN is received in the device, the screen, where we should enter it. is not shown to the user so the registration can not be completed.
blocking-b2g: --- → 2.0?
Whiteboard: ft:Loop [blocking][platform]
Attached patch v1 (obsolete) — Splinter Review
The fix is quite easy. I am also taking the chance to write the tests for MobileIdentityClient.jsm and close bug 1044051.
Attached patch v1Splinter Review
Sam, the reason of this issue is that the server changed from a 200 ok to a 204 no content response and we were not handling this case appropriately in the client.

I added the tests for this at bug 1044051.

Attachment #8482333 - Attachment is obsolete: true
Attachment #8482709 - Flags: review?(spenrose)
Comment on attachment 8482709 [details] [diff] [review]

See comment on review.
Attachment #8482709 - Flags: review?(spenrose) → review+
blocking-b2g: 2.0? → 2.0+
Priority: -- → P1
Hardware: x86 → ARM
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S4 (12sep)
Note that due to recent policy changes, all B2G uplifts needs approval now regardless of blocking status. Please request aurora and b2g32 approval on this patch when you get a chance. Sorry for the inconvenience.
Flags: needinfo?(ferjmoreno)
Comment on attachment 8482709 [details] [diff] [review]

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Not sure when it changed, but the server part of this feature were sending a 200 instead of the current 204 response, which broke the client.
User impact if declined: The user won't be able to manually enter the phone number to be verified and shared via the mobile ID mechanisms.
Testing completed: Manual tests and unit tests added.
Risk to taking this patch (and alternatives if risky): No risk.
String or UUID changes made by this patch: None
Attachment #8482709 - Flags: approval-mozilla-b2g32?
Attachment #8482709 - Flags: approval-mozilla-aurora?
Flags: needinfo?(ferjmoreno)
Depends on: 1044051
Attachment #8482709 - Flags: approval-mozilla-b2g32?
Attachment #8482709 - Flags: approval-mozilla-b2g32+
Attachment #8482709 - Flags: approval-mozilla-aurora?
Attachment #8482709 - Flags: approval-mozilla-aurora+
Verified on trunk.
Blocks: 1064249
Also verified fixed on 2.1.
Attached video video
This issue has been verified successfully on Woodduck 2.0 and Flame 2.0/2.1/2.2
See attachment: Verify_1045581.MP4
Reproducing rate: 0/5

Woodduck 2.0 build:
Gaia-Rev        ead3b72a84512750bc5faff4e9e8faa1715c0d05
Gecko-Rev       8d40d6480ee0e628b0f7655dcd6ff79a2f2fbcfc
Build-ID        20141211050313

Flame 2.0 build
Gaia-Rev        856863962362030174bae4e03d59c3ebbc182473
Build-ID        20141210000202
Version         32.0

FLame 2.1 build:
Gaia-Rev        c226db212db4d824c09617cd6dc407b2d4258d9b
Build-ID        20141210001201
Version         34.0

Flame 2.2 build:
Gaia-Rev        e17c5656dbf517d48fb61ac9bc92119e023fd717
Build-ID        20141210040201
Version         37.0a1
You need to log in before you can comment on or make changes to this bug.