356 bytes, text/html
User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11 Steps to reproduce: 1. Launch Message application. 2. Edit a new message. 3. Input characters in edit area. Actual results: Although inputting characters is ok, no character count shows. User cannot get the information how many characters he has input for the message. Expected results: The character count should show for user. Build Information: gecko: revision="3cbade1974968bb1e0fbb0c3386239715244a7a7" gaia: revision="aab72f365d73f624ede32b522f27d072c409e42e" gonk-misc: revision="654358494ba601a46ef9838debc95417ae464cc6" dalvik: revision="ca1f327d5acc198bb4be62fa51db2c039032c9ce" librecovery: revision="e1bd90051c9e937221eb1f91c94e3cde747311a7" moztt: revision="6ee1f8987ef36d688f97064c003ad57849dfadf2" external/jsmin: revision="cec896f0affaa0226c02605ad28d42df1bc0e393" external/opensans: revision="b5b4c226ca1d71e936153cf679dda6d3d60e2354" device/qcom/b2g_common/mozilla-b2g: revision="41c17a6abfd5f488ec99d9aa246f5b07583403c7"
This doesn't look security sensitive to me.
By design, we will have a number for text amount after it's over 144 (which is the maximum amount of an English message).
Status: UNCONFIRMED → RESOLVED
blocking-basecamp: --- → ?
Last Resolved: 6 years ago
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Resolution: --- → INVALID
Renominating this bug. It is not clear what's happening for Spain, here the maximum amount is 160 chars. Will the counter appear when changing from 160 to 161? It is important to have the number of characters and also when changing from one message to the second one.
blocking-basecamp: --- → ?
Hi, We think that could be an important issue. Carriers require this, as users are very sensitive to costs associated to SMS, and they try to avoid the sending of concatenated SMS. Bug reopened for discussing it during triage. Thanks, David
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Daniel, could you confirm if this is a certification requirement or not ? Thanks.
Hi, Just a suggestion, I think a good solution could be to have something like: a) Case 1: Editing a message, only one single message (no concatenation limit reached) >> counter_chars |-> just a counter for the number of chars written b) Case 2: Editing a message, more than one message (concatenation limit reached) >> counter_chars/counter_msg |-> a counter for the number of chars written |-> and also a counter for the number of messages to be sent Daniel is on holidays right now, I think this would be a certification requirement. I'd suggest to include it as a certification requirement. Thanks! David
Triage: BB+, P1 - potential cert blocker and also very important for market that is cost sensitive
blocking-basecamp: ? → +
Priority: -- → P1
Target Milestone: --- → B2G C4 (2jan on)
(In reply to Joe Cheng [:jcheng] from comment #7) > Triage: BB+, P1 - potential cert blocker and also very important for market > that is cost sensitive Why is it a cert blocker? If I read the bug issue it seems like the issue is about not having always a character counter. There is one once you go past 160 characters (depending on the encoding it could be less). If this one is not enough for certification/user cost sensitive information please block again on this bug.
blocking-basecamp: + → ?
Daniel, please renominate if required for certification
blocking-basecamp: ? → -
tracking-b2g18: --- → +
(In reply to David Scravaglieri [:scravag] from comment #9) > Daniel, please renominate if required for certification The discussion has diverged that much since the beginning that let me clarify what should be a certification blocker: The user must be informed about the amount of SMSs that are going to be concatenated when that amount is more than 1 (Note that the amount of chars per SMS depends on the encoding). For concatenated SMSs (messages that require more than 1 SMS because of its length) the user must be informed about the amount of chars that are still available in the SMS before requiring a new one to be concatenated. When the maximum size of an SMS is reached, user must be informed about it. Anything else is a nice to have.
Agree with Daniel & Vivien. Currently we have a counter and it shows info when you exceed the limit for the first message and the number of messages that you are going to send, and we are following the specs from UX. David, probably we should reduce the severity and milestone for this one, because currently we have a counter and it's working! And this bug sounds as an improvement.
Hi Ayman, Based on comment #10, do you have any suggestion or refinement about current SMS counter UX? Thanks.
Flags: needinfo?(dscravaglieri) → needinfo?(aymanmaat)
(In reply to Steve Chung from comment #13) > Hi Ayman, > Based on comment #10, do you have any suggestion or refinement about current > SMS counter UX? Thanks. Hey there Steve Referencing... wireframe pack: HTML5_SMS_20121212_R2S1_V8.0 page: 17 annotation: 02 and 03 It would seem to me that Dev has followed the specification exactly, so there is no problem there. However referencing comment #10 "For concatenated SMSs (messages that require more than 1 SMS because of its length) the user must be informed about the amount of chars that are still available in the SMS before requiring a new one to be concatenated." With that in mind I would say that an extension to what i specified and an enhancement in UX would be to count down the last ten characters in the first SMS packet before the user moves to the second SMS packet. Let me know if you require any further clarification.
Whiteboard: [triaged: 1/24] → [triaged: 1/24], interaction, [UX-P3]
Created attachment 710555 [details] Patch for refine the message counter display timing It's a simple and low-risk patch and user could have better use experience while composing the message.
Attachment #710555 - Flags: review?(fbsc)
Comment on attachment 710555 [details] Patch for refine the message counter display timing NOTE: If blocking-basecamp+ is set, just land it for now. [Approval Request Comment] Bug caused by (feature/regressing bug #): feature User impact if declined: It would be nice to notify the use while the end of the first message, not until the second message concatenated. Testing completed: The result should be the same as #813689 Risk to taking this patch (and alternatives if risky): None
Attachment #710555 - Flags: approval-gaia-v1?
We'll approve this once it has been r+'d.
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → wontfix
Attachment #710555 - Flags: review?(fbsc) → review+
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago → 6 years ago
Resolution: --- → FIXED
Already reviewed and landed in master
Comment on attachment 710555 [details] Patch for refine the message counter display timing Approving low risk fix that improves the UX of SMS.
Attachment #710555 - Flags: approval-gaia-v1? → approval-gaia-v1+
Batch edit: Bugs still affected on b2g18 after 2/13 merge to v1.0.1 branch are affected on v1.0.1 branch.
v1-train: 984f41115b62c717aaf2f268c8c31462104a64d3 v1.0.1: c74078f8e65edaeb05d83e779be133e5ba301d09
status-b2g18: affected → fixed
status-b2g18-v1.0.1: affected → fixed
You need to log in before you can comment on or make changes to this bug.