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. ACTUAL RESULT Loop remains permanently trying to connect. EXPECTED RESULT Some message should be displayed. (or not be able to leave the field blank)

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 https://github.com/mozilla-services/msisdn-gateway/blob/master/msisdn-gateway/routes/sms.js#L119 - Verification promise is not working as expected https://mxr.mozilla.org/mozilla-central/source/services/mobileid/MobileIdentityVerificationFlow.jsm#67 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!

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.

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.

[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.

The fix is quite easy. I am also taking the chance to write the tests for MobileIdentityClient.jsm and close bug 1044051.

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. Thanks!

Comment on attachment 8482709 [details] [diff] [review] v1 See comment on https://bugzilla.mozilla.org/show_bug.cgi?id=1044051 review.

Thanks Sam! https://tbpl.mozilla.org/?tree=Try&rev=075762ea4157

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.

Comment on attachment 8482709 [details] [diff] [review] v1 [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

https://hg.mozilla.org/releases/mozilla-aurora/rev/c839641f42ea https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/3d2f067b6821

Verified on trunk.

Also verified fixed on 2.1.

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 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/2d0860bd0225 Build-ID 20141210000202 Version 32.0 FLame 2.1 build: Gaia-Rev c226db212db4d824c09617cd6dc407b2d4258d9b Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/cf8bebfa4703 Build-ID 20141210001201 Version 34.0 Flame 2.2 build: Gaia-Rev e17c5656dbf517d48fb61ac9bc92119e023fd717 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/be1f49e80d2d Build-ID 20141210040201 Version 37.0a1