We have a situation at the moment in the messages app where we allow invalid strings to be entered into the to field of a new message and, upon send, for the message to attempt to be 'sent to' these invalid strings. It would therefore be a practical enhancement to the contacts app and to the UX of the contacts app to include some upfront string validation of the content in the to field to ensure strings are valid. This would also align us to the UX of other platforms in the market related bugs are here https://bugzilla.mozilla.org/show_bug.cgi?id=888245 https://bugzilla.mozilla.org/show_bug.cgi?id=823392[SMS/MMS] Allow only valid strings in the To field Very rough sketch of what this UX could look like attached. Sketch would need more detail before development.

(In reply to ayman maat :maat from comment #0) > Created attachment 792689 [details] > HTML5_SMS-MMSUserStorySpecifications_invalidnumber_20130819_V0.2.pdf > > We have a situation at the moment in the messages app where we allow invalid > strings to be entered into the to field of a new message and, upon send, for > the message to attempt to be 'sent to' these invalid strings. > > It would therefore be a practical enhancement to the contacts app and to the > UX of the contacts app to include some upfront string validation of the > content in the to field to ensure strings are valid. I'm assuming you meant Messages app? > > This would also align us to the UX of other platforms in the market Can you cite these platforms for development reference, thanks

Developer notes: - Should be handled in "onSendClick", or between user pressing "Send" and the actual operation

(In reply to Rick Waldron from comment #2) > Developer notes: > > - Should be handled in "onSendClick", or between user pressing "Send" and > the actual operation Hang on a moment Rick, this bug has not gone through backlog grooming yet and so has not been flagged. Flagging Koi? for nomination to V1.3

This comment is brought over from duplicate bug 907090 as it is relevant here (In reply to Stephany Wilkes from comment #1) > Ayman, are the invalid strings causing any sort of user error (i.e. > attempting to send an SMS/MMS and failing, either obviously or silently)? > We're in triage and trying to make a determination as to whether this is leo > or can be koi. Thanks! Well yes and no... referencing bugs 88245 and 823392 upon send and fail there is currently a very generic error messages 'message could not be sent' (so yes) however the invalid number, upon tap on header of thread, can then be used to call, create new contact add to new contact etc (so no). I would say that this bug needs to be addressed asap, however i am also sensitive to the fact that this will probably also require some deep surgery from a dev perspective at front and back end so in view of that i flagged it Koi? ...but if triage wish to bump it to Leo+, from a UX perspective, i would be more than support that decision.

we should look at it for koi (v1.2) and if this is too much work then change it in v1.3 If the error message exists at the moment the user is informed that something is wrong (generic message). So its not failing silently.

FTR we discussed this a lot already in bug 823392, this is not easy to do correctly. The task by itself is probably not so huge, what's huge is knowing what to do so that we don't try to be too clever, ie forbidding perfectly correct numbers. As Ayman said on bug 823392 we can discuss this in Oslo with all the relevant people.

add to backlog 891754

bug 920546 will change some things for 1.2, and bug 914103 for 1.3. They won't change anything for recipients that look like valid numbers though, and I think this is what this bug is about. bug 823392 already exists about general error messages. The current displayed error message is wrong (bug 917954) and we really must change it anyway. Here, I'd like to build on what bug 920546 and bug 917954 will do, so that if after sending to a recipient we get an error, we can try to check and understand if the error is because the recipient is invalid, and show it accordingly. Does that sound good ?

Note that the mechanism to do this is not easy. Currently, we switch to the thread view as soon as we press "send", and that would mean we'd switch back to the "new recipient" view if there is an error. And I really don't know what to do in case of sending to several recipients. So lots of unanswered answers yet.

"unanswered questions" of course

QAWANTED to see if it still happens.

We can still enter invalid strings starting with a digit. This is so to permit phone "numbers" like "1-800-HELLO-WORLD" that's used a lot in some countries. I think there is a bug about only this case, BTW. But we now forbid invalid strings that do not start with a digit (except emails).

I'm unsure what characters are considered 'invalid' in this case? According to bug 823392 that was duped to this bug, a semicolon is considered invalid. What else? On latest 3.0 it does not allow user to enter a semicolon as a beginning character (tapping on it on keyboard does not input any character), and if it's entered after a number, it acts as if user has entered the comma key and it becomes the separator between two sets of numbers. We will need a list of invalid characters to test this.

(In reply to Pi Wei Cheng [:piwei] from comment #15) > We will need a list of invalid characters to test this. Jenny, Not sure if this was defined before. Do you know what are considered as invalid?

It's any character that can't be part of a phone number (eg: any word characters). But I remove the qawanted because it's not necessary to waste your time given my answer in comment 14 :) The current imperfect plan is comment 9 and comment 10.

Hi Wesley, I don't think UX has defined such list before. There can be quite a lot of invalid string variations that doesn't seem practical to try filter out every one of them. We are already doing some basic filtering which I believe should cover most cases. Thanks!

canceling NI as qawanted is longer needed.