Closed
Bug 887712
Opened 11 years ago
Closed 11 years ago
[SMS/MMS] Make editable cursor element "zero width" until any user interaction
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect, P2)
Tracking
(blocking-b2g:leo+, b2g18 fixed, b2g-v1.1hd fixed)
People
(Reporter: carlosmartinez, Assigned: rwaldron)
Details
(Whiteboard: MMS_TEF, [u=commsapps-user c=messaging p=0], TaipeiMMS, [LeoVB+] )
Attachments
(3 files)
Tested in unagi with Gecko-94d5935 Gaia-ffd437d STR: 1-Open contacts app and create two contacts (e.g. John Smith and Wilma Wiggle) 2-Open SMS app 3-Select both contacts to add them to the "TO" field Expected result --> You can see the name of the contacts already added Actual result --> The name of the contacts is hidden below the header
Updated•11 years ago
|
Whiteboard: MMS_TEF
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → waldron.rick
Assignee | ||
Comment 1•11 years ago
|
||
This is expected behaviour. Those two contacts take up enough room to push the "editable placeholder input area" to the next line. The behaviour follows that defined on page 19 & 20 of the attached specification
Reporter | ||
Comment 2•11 years ago
|
||
In page 19 of this document, with 2 recipients, contact names are visible and when you add a third recipient, the first two are hidden below the header, so I don´t think this is the expected behaviour.
Comment 3•11 years ago
|
||
ni? to FFOS UX team to review what's expected behavior for this.
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?
Comment 4•11 years ago
|
||
Clearing the needinfo for FFOS-UX and reassigning to Ayman, as this is his domain.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(aymanmaat)
Comment 6•11 years ago
|
||
This is entirely implemented to spec. There is only about 1 and a half visible lines in page 19. If the contact names are short (try "bob" and "joe") you can fit two recipients on a single line and it looks correct. This is worksforme? (waiting to hear ayman's response too)
Updated•11 years ago
|
Whiteboard: MMS_TEF → MMS_TEF, [u=commsapps-user c=messaging p=0]
Comment 7•11 years ago
|
||
Can we reconsider the criticity of this issue and delay it to koi?
Assignee | ||
Comment 8•11 years ago
|
||
(In reply to Beatriz Rodríguez [:brg] from comment #7) > Can we reconsider the criticity of this issue and delay it to koi? The bug just needs to be closed, it works exactly as specified in the WF and according to the visual specs. There is no way to know how much horizontal (and therefore vertical) two recipient entries will require.
Comment 9•11 years ago
|
||
(In reply to Rick Waldron from comment #8) > (In reply to Beatriz Rodríguez [:brg] from comment #7) > > Can we reconsider the criticity of this issue and delay it to koi? > > The bug just needs to be closed, it works exactly as specified in the WF and > according to the visual specs. There is no way to know how much horizontal > (and therefore vertical) two recipient entries will require. No it does not work exactly as specified at no point is the behavior i am seeing the intended design behaviour. I cannot close this bugs as I am not happy with the result i am seeing. I think we all agree that this is sub optimum UX as the user has to drag down to see the names of the contacts and we all agree that this is certainly not what was intended in the design. Its especially poor as when the user moves focus to the 'message input field' the content of the 'to field' remains suspended and therefore only partially visible. None of this was the intention during specification and I am looking for the developers to propose solution. As a starter i am wondering if it possible to 'suppress' going to next line until the user actually writes something? This way we avoid having current contacts pushed under the header and a vast expanse of white space where they should be.
Flags: needinfo?(aymanmaat)
Comment 10•11 years ago
|
||
Thank you for clarifying, Ayman! If the intended design behavior is not implemented the bug is not complete. From what we can see of this, the user will have difficulty accomplishing their task, so it's important to get it right.
Assignee | ||
Comment 11•11 years ago
|
||
(In reply to ayman maat :maat from comment #9) > None of this was the intention during specification and I am looking for the > developers to propose solution. I completely understand, but this is the result of designing a UI that was meant to be implemented with HTML and CSS. > As a starter i am wondering if it possible > to 'suppress' going to next line until the user actually writes something? The reasons for the next line appearing are because the "editable" element, which is the last element of the recipient list: 1. Has the cursor 2. Has width (which is why the browser pushes it to the next line, based on the CSS for the container element) 3. Is the target element for input (without it, we won't know if the user has written something) > This way we avoid having current contacts pushed under the header and a vast > expanse of white space where they should be. Unfortunately, it's just not that simple.
Assignee | ||
Updated•11 years ago
|
Summary: [SMS/MMS] Contacts in "To" field are hidden below the header → [SMS/MMS] Make editable cursor element "zero width" until any user interaction
Assignee | ||
Comment 12•11 years ago
|
||
Attachment #772272 -
Flags: review?(gnarf37)
Comment 13•11 years ago
|
||
Comment on attachment 772272 [details] [review] Github Pull Request https://github.com/mozilla-b2g/gaia/pull/10849 comment on the pull request - please r? me again when updated: https://github.com/mozilla-b2g/gaia/pull/10849#issuecomment-20699865
Attachment #772272 -
Flags: review?(gnarf37) → review-
Updated•11 years ago
|
Flags: in-moztrap?
Assignee | ||
Updated•11 years ago
|
Attachment #772272 -
Flags: review- → review?(gnarf37)
Comment 14•11 years ago
|
||
Ayman, Can you please take a look at two branches for me and test this: First: https://github.com/gnarf/gaia/compare/zero-width I see one problem with this solution. The cursor is lost when you type a long recipient - you have no idea that you can type. Try "aaaaaaaaaaaaaaaaaaaaaaaaaaaa" as a recipient name and hit enter, you'll see what I mean. The lack of seeing the cursor to type seems very disturbing and wrong. This completely contradicts the steps to reproduce for this bug. I have a propoal --- Second: https://github.com/gnarf/gaia/compare/zero-width-test-1 This solution only shows the "blank line" described in the bug when the typing area is still focused. So if you tap outside of the recipients area, the contacts that have scrolled off the top are visible again. Is this satisfactory? ---- Do either of these solutions work? Or do we still need to keep looking for the right solution?
Flags: needinfo?(aymanmaat)
blocking-b2g: leo+ → leo?
Whiteboard: MMS_TEF, [u=commsapps-user c=messaging p=0] → MMS_TEF, [u=commsapps-user c=messaging p=0],[leo-triage]
Comment 15•11 years ago
|
||
(In reply to Corey Frang [:gnarf] [:gnarf37] from comment #14) > Ayman, > > Can you please take a look at two branches for me and test this: > > First: https://github.com/gnarf/gaia/compare/zero-width > > I see one problem with this solution. The cursor is lost when you type a > long recipient - you have no idea that you can type. Try > "aaaaaaaaaaaaaaaaaaaaaaaaaaaa" as a recipient name and hit enter, you'll see > what I mean. The lack of seeing the cursor to type seems very disturbing > and wrong. This completely contradicts the steps to reproduce for this bug. > indeed i am also concerned with this pontoon as the user does not see the cursor: 1) in-between when finishing the 1st recipient and starting the 2nd 2) when the user switches cursor focus from the message field back to the 'to field' when the 'to field' already has content. Its not clear to the user in this scenario that focus has actually been changed …So I agree that this lack of feedback is disorientating and therefore this is not an option to pursue > I have a propoal --- > > Second: https://github.com/gnarf/gaia/compare/zero-width-test-1 > > This solution only shows the "blank line" described in the bug when the > typing area is still focused. So if you tap outside of the recipients area, > the contacts that have scrolled off the top are visible again. Is this > satisfactory? > Thats Perfect Corey. Good work :) Lets go with the second option: https://github.com/gnarf/gaia/compare/zero-width-test-1 Thanks
Flags: needinfo?(aymanmaat)
Comment 16•11 years ago
|
||
Comment on attachment 772272 [details] [review] Github Pull Request https://github.com/mozilla-b2g/gaia/pull/10849 Couple of nit based comments left on the pull - r=me though - Thanks for updating this to work with the css approach rick!
Attachment #772272 -
Flags: review?(gnarf37) → review+
Assignee | ||
Comment 17•11 years ago
|
||
Landed deeba30eb02ae1286ba277edb8f681c85bee1ca0
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 18•11 years ago
|
||
https://github.com/mozilla-b2g/gaia/commit/deeba30eb02ae1286ba277edb8f681c85bee1ca0
blocking-b2g: leo? → leo+
Whiteboard: MMS_TEF, [u=commsapps-user c=messaging p=0],[leo-triage] → MMS_TEF, [u=commsapps-user c=messaging p=0], TaipeiMMS
Target Milestone: --- → 1.1 QE4 (15jul)
Comment 19•11 years ago
|
||
Uplifted deeba30eb02ae1286ba277edb8f681c85bee1ca0 to: v1-train: b50b787587d3110ee7df5c75ee65d6ecd8698115
status-b2g18:
--- → fixed
Comment 20•11 years ago
|
||
Checked with unagi device v1-train 07/17 build:
Gecko-2d17cfb
Gaia-c506c50
ref. ril
> I have a propoal ---
>
> Second: https://github.com/gnarf/gaia/compare/zero-width-test-1
>
> This solution only shows the "blank line" described in the bug when the
> typing area is still focused. So if you tap outside of the recipients area,
> the contacts that have scrolled off the top are visible again. Is this
> satisfactory?
>
This is working as described here.
Ni Ayman to double check with UX that this is working also ok for them before verifing.
Thanks
Flags: needinfo?(aymanmaat)
Comment 21•11 years ago
|
||
(In reply to Isabel Rios [:isabel_rios] from comment #20) > Checked with unagi device v1-train 07/17 build: > Gecko-2d17cfb > Gaia-c506c50 > ref. ril > > > I have a propoal --- > > > > Second: https://github.com/gnarf/gaia/compare/zero-width-test-1 > > > > This solution only shows the "blank line" described in the bug when the > > typing area is still focused. So if you tap outside of the recipients area, > > the contacts that have scrolled off the top are visible again. Is this > > satisfactory? > > > > This is working as described here. > > Ni Ayman to double check with UX that this is working also ok for them > before verifing. > > Thanks as per comment 15, fine by me
Flags: needinfo?(aymanmaat)
Updated•11 years ago
|
Status: RESOLVED → VERIFIED
Whiteboard: MMS_TEF, [u=commsapps-user c=messaging p=0], TaipeiMMS → MMS_TEF, [u=commsapps-user c=messaging p=0], TaipeiMMS, [LeoVB+]
Comment 22•11 years ago
|
||
v1.1.0hd: b50b787587d3110ee7df5c75ee65d6ecd8698115
status-b2g-v1.1hd:
--- → fixed
Updated•11 years ago
|
Flags: in-moztrap? → in-moztrap?(mclemmons)
Comment 23•11 years ago
|
||
https://moztrap.mozilla.org/manage/cases/?filter-id=9275 New test case created to cover this bug.
Flags: in-moztrap?(mclemmons) → in-moztrap+
Updated•11 years ago
|
Attachment mime type: text/plain → text/x-github-pull-request
You need to log in
before you can comment on or make changes to this bug.
Description
•