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)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:leo+, b2g18 fixed, b2g-v1.1hd fixed)

VERIFIED FIXED
1.1 QE4 (15jul)
blocking-b2g leo+
Tracking Status
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
Whiteboard: MMS_TEF
Assignee: nobody → waldron.rick
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
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.
ni? to FFOS UX team to review what's expected behavior for this.
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?
Clearing the needinfo for FFOS-UX and reassigning to Ayman, as this is his domain.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(aymanmaat)
Triage - blocking
blocking-b2g: leo? → leo+
Flags: needinfo?
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)
Whiteboard: MMS_TEF → MMS_TEF, [u=commsapps-user c=messaging p=0]
Priority: -- → P2
Can we reconsider the criticity of this issue and delay it to koi?
(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.
(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)
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.
(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.
Summary: [SMS/MMS] Contacts in "To" field are hidden below the header → [SMS/MMS] Make editable cursor element "zero width" until any user interaction
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-
Flags: in-moztrap?
Attachment #772272 - Flags: review- → review?(gnarf37)
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]
(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 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+
Landed deeba30eb02ae1286ba277edb8f681c85bee1ca0
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
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)
Uplifted deeba30eb02ae1286ba277edb8f681c85bee1ca0 to:
v1-train: b50b787587d3110ee7df5c75ee65d6ecd8698115
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)
(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)
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+]
v1.1.0hd: b50b787587d3110ee7df5c75ee65d6ecd8698115
Flags: in-moztrap? → in-moztrap?(mclemmons)
https://moztrap.mozilla.org/manage/cases/?filter-id=9275 

New test case created to cover this bug.
Flags: in-moztrap?(mclemmons) → in-moztrap+
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.

Attachment

General

Created:
Updated:
Size: