Closed Bug 941353 Opened 8 years ago Closed 8 years ago
[B2G][SMS] When more than 12 recipients are added to a SMS message user is not able to edit message field
Description: If user adds more than 12 recipients to an SMS message by clicking the '+' icon in the address field, the user is no longer able to edit the message body field. Repro Steps: 1) Updated Buri to Build ID: 20131120004000 2) Start Messages app with more than 12 numbers in contact list 3) Create new message and add more than twelve recipients using '+' icon 4) Attempt to type anything in message field Actual: More than 12 recipients in a single message cause user to not be able to edit message field. Expected: Ability to edit message field not restricted by number of recipients. Environmental Variables Device: Buri v 1.2 COM RIL Build ID: 20131120004000 Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/2d454e0de2ed Gaia: 5ec2963fff60492c840707df8d8090f9908a5251 Platform Version: 26.0 RIL Version: 01.02.00.019.102 Firmware Version: V1.2_US_20131115 Notes: Repro frequency: 3/3, 100% Link to failed test case: See attached: video clip
Does not reproduce in 1.1 Environmental Variables Device: (example:Leo v 1.1.0 Mozilla/ COM RIL) Build ID: 20131119041201 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/7c3cfc0936ca Gaia: b585b32441fafa67f2b4582db23be5f3a2afab21 Platform Version: 18.1 RIL Version: 01.01.00.019.281 Firmware Version: D300f10a
Technically this is legitimate use case if you were sending out a message to a large array of people (e.g. party happening at X location). So not being able to do that would be pretty bad.
blocking-b2g: --- → koi?
Wow, interesting one. We're using transformations to move the recipients panel, so here it seems the touch subsystem thinks the recipients panel is over the message composers whereas it's not thanks to the transformation. I'll try to reproduce today and especially will try to disable fluffing and see if this helps.
Assignee: nobody → felash
As a follow-up, * without the event fluffing, it still happens. * I got a funny display with invalid recipients too when scrolling. * I couldn't make a reduced testcase where the bug appeared yet. Discussing with Nical, he thinks the funny display is more a layout issue, and I think the input issue is the same reason. Will go on doing a testcase but my hands are full right now, so probably not before next week.
This issue started to occur Buri 1.2 Build ID: 20131026004003 Gaia de70f4d9b7a8dd3ba2565184735094eaa2bd3d18 SourceStamp 780de7966fc0 Build ID: 20131026004003 Version 26.0a2 Last working Buri 1.2 Build ID: 20131025004000 Gaia 606517ceafe0950c2b89822d5f13353743334f2c SourceStamp 5eabd267ef04 BuildID 20131025004000 Version 26.0a2
No commit in the sms app in this range. Sarah, you haven't put the hashes for Gecko?
(In reply to Julien Wajsberg [:julienw] from comment #6) > No commit in the sms app in this range. > > Sarah, you haven't put the hashes for Gecko? Source stamp = gecko commit hash. I'll include a push log in a second.
(In reply to Brogan Zumwalt from comment #1) > Does not reproduce in 1.1 > > Environmental Variables > Device: (example:Leo v 1.1.0 Mozilla/ COM RIL) > Build ID: 20131119041201 > Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/7c3cfc0936ca > Gaia: b585b32441fafa67f2b4582db23be5f3a2afab21 > Platform Version: 18.1 > RIL Version: 01.01.00.019.281 > Firmware Version: D300f10a Device line should read "Device: Buri v 1.1 COM RIL"
It could conceivably be either although 929362 is more likely.
But it feels more like a Gaia bug to me. Maybe something we did in Gecko revealed a Gaia bug.
Yes, I'm pretty sure this is a bug in the SMS app. The #messages-to-field's border-box extends well below its visible contents. This is because it contains #messages-recipients-list-container, whose height grows with the number of recipients. #messages-recipients-list-container has transform:translateY(calc(-100% + 4.5rem)), which makes it render in the right place, but #messages-to-field still grows in height to include the height of #messages-recipients-list-container at its untransformed position. This is all correct per the CSS specs. You might be able to fix this by adding height:0 to #messages-to-field and #messages-subheader.
Mmm ok I think I understand, thanks a lot roc. I'll try to do a patch next week.
See previous attachments: reproduced the issue as correctly identified by Roc in a simpler testcase, and I verified the suggested fix work in that case. I'm working on applying this in the Messages app now.
Hey Steve, a very simple patch for a very annoying bug :) see pull request at https://github.com/mozilla-b2g/gaia/pull/14038 * Add a height: 0 property to the to-field element --- apps/sms/style/sms.css | 1 + 1 file changed, 1 insertion(+) I do also see a graphic issue when using invalid recipients, I'll file another bug and try to do a testcase.
Attachment #8338205 - Flags: review?(schung)
Comment on attachment 8338205 [details] [diff] [review] patch v1 Review of attachment 8338205 [details] [diff] [review]: ----------------------------------------------------------------- LGTM. Nice catch for the root cause.
Attachment #8338205 - Flags: review?(schung) → review+
master: d3a0e45b26a0698b62ce0edcb926e3053a2fba73 Thanks all!
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Uplifted d3a0e45b26a0698b62ce0edcb926e3053a2fba73 to: v1.2: d4e7d71397a54d882502688a9a8bd4a61b633b5c
The bug does not reproduce. I am able to type a message while having 12+ recipients in the message app on the latest Buri 1.2 and Master 1.3 builds. 1.2 Environmental Variables: Device: Buri v1.2 COM RIL BuildID: 20131204004003 Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/244e98241b2c Gaia: c8f14ad3950d59ba13d7639eff02d080060bb3ce Version: 26.0 RIL Version: 01.02.00.019.102 Firmware Version: V1.2_20131115 1.3 Environmental Variables Device: Buri v1.3 Mozilla RIL Build ID: 20131203040236 Gecko: http://hg.mozilla.org/mozilla-central/rev/8648aa476eef Gaia: 31808a29cfcffa584b6a88b4f1e515387f485a1b Platform Version: 28.0a1 Firmware Version: v1.2_20131115
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.