877590 - [MMS] Recipients composer switch to single line for any input interaction

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::SMS, defect, P3)

Description

[Borja Salguero [:borjasalguero]]

When focus in the 'TO' field the 'recipients-container' should be pushed up until reaching one line. Currently this is not working, and if you type with this container pulled down, recipients are not working at all (check video).

http://youtu.be/yYu4ZxVd-1s

Comment 1

[bhavana bajaj [:bajaj]]

Borja, can you please help us get a clear STR on this ?
We understand there may be an issue with getting the recipients being added, but the problem is not entirely clear even after watching the video.

Comment 2

[Borja Salguero [:borjasalguero]]

Hi Bhavana,

Mainly the problem is that when the recipients container is pushed down *we should not be able* to type (this functionality it's only for showing the recipients), and currently you can type :S. 
When the user tries to add a new one, the recipients container should be pulled up and focused properly.

In this case, this funcionality is not working as expected, so we are letting the user to type in the wrong scenario, and furthermore  the 'focus' is moved from this container to the text field of the composer randomly...

If you have new doubts dont hesitate to ask! Thanks ;)

Comment 3

[Borja Salguero [:borjasalguero]]

Rick, Could you take a look? Thanks!

Comment 4

[Dietrich Ayala (:dietrich)]

Corey and I both tested and cannot reproduce this on v1-train, so resolving WFM. Please re-open if you can still reproduce.

Comment 5

[Borja Salguero [:borjasalguero]]

Quite easy to reproduce. STR:
- Add several recipients to the recipientes container.
- Pull down to see all recipients
- Tap for editing a new one

EXPECTED:
- Recipients container is pushed up and you edit the new recipient in *one* line layout

CURRENTLY:
- You can add a new recipient with the container pulled down.

Furthermore, currently when editing/adding a new recipient when we have 5 or 6, I can reproduce the same as in the video. But this will be fixed avoiding the previously explained STR.

Comment 6

[Mark Shiao]

Attachment: link to pull request

Hi Steve,

Can you please review my fix. 

I updated the removeEventListener's capture event so it matches the addEventListener allowing it to correctly remove events.

I've also added a check for view.state = multiline when user clicks and fires off fat finger mode by resetting the list to singleline and focusing on the last recipient element.  

I've also found and fixed another bug with this patch.  The bug occurs when you select a recipient, enter into edit mode then drag down the list.  If you enter something, the view.state returns to singleline but never scrolls to the last roll and the list appears cutoff.

Let me know if you find any issues.

Thanks,
Mark

Comment 7

[Steve Chung [:steveck]]

Comment on attachment 759037 [details]
link to pull request

I left some comment in https://github.com/mozilla-b2g/gaia/pull/10237#discussion_r4565169. Not quite sure that it's a correct behavior for the recipient.

Comment 8

[Rick Waldron [:rwaldron]]

There are two issues here:

1. The focus/blur issue
2. The single/multiline issue

#1 was caused by https://github.com/mozilla-b2g/gaia/commit/00f26aedca54aa1709751f6a942a959b1898a10b which has been reverted and new patch that addresses that bug is ready to land today

#2 Can be addressed orthogonally when the new patch lands

Comment 9

[Steve Chung [:steveck]]

Comment on attachment 759037 [details]
link to pull request

I left some comment in https://github.com/mozilla-b2g/gaia/pull/10237#discussion_r4565169. Not quite sure that it's a expected behavior for the recipient.

Comment 10

[Rick Waldron [:rwaldron]]

Steve, It's explained in the comment above the line of code you're asking about.

I'm updating the title to more accurately reflect the issue this bug will address. I've written several tests for the patch submitted by Mark

Comment 11

[Mark Shiao]

Steve

Updated so that if user pans list to multiline during edit mode and length >= 1, it'll return the view to singleline and continue focus on the recipient.

Thanks,
Mark

Comment 12

[Mark Shiao]

Hi Ayman,

We would like to get your feedback on some ux issues regarding this bug.  

1)Tapping on the 'to-field' should go to 'single-line' in every case? Can you validate this?  The discussions is at https://github.com/mozilla-b2g/gaia/pull/10237

2)Users should never be able to edit in multiline view? Currently, there's a situation where a user can initiate a recipient's edit mode, type a few word, then pan into multiline mode and continue typing in multiline.  I would prefer to keep the behavior consistent and return them to singleline mode.  What do you think?

Thanks,
Mark

Comment 13

[ayman maat :maat]

(In reply to Mark Shiao from comment #12)
> Hi Ayman,
> 
> We would like to get your feedback on some ux issues regarding this bug.  
> 
> 1)Tapping on the 'to-field' should go to 'single-line' in every case? Can
> you validate this?  The discussions is at
> https://github.com/mozilla-b2g/gaia/pull/10237

Referencing: 
wireframe pack HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0
page 19
frame 7. Closing the to field

	The ‘to’ field is closed be the user:
	1) typing on the keyboard when the focus is still on the ‘to’ field
	2) tapping on the ‘your message’ textfield and so changing focus to the ‘your message field’

I did not explicitly specify that tapping on the 'to-field' (outside of a contact module) should return an expanded 'to-field' to a single line it was implied. I see no reason why the to-field should not behave this way. It would be a logical and pragmatic progression of the UX flow so far specified, and indeed there is precedence for such behavior within our benchmarks. Nevertheless I am happy to listen to a reasoned argument against such an implementation if you can provide one. If not then tapping on the 'to-field' (outside of a contact module) returning an expanded 'to-field' to a single line remains the requirement.

> 
> 2)Users should never be able to edit in multiline view? Currently, there's a
> situation where a user can initiate a recipient's edit mode, type a few
> word, then pan into multiline mode and continue typing in multiline.  I
> would prefer to keep the behavior consistent and return them to singleline
> mode.  What do you think?

Referencing: 
wireframe pack HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0
page 19
frame 7. Closing the to field

	The ‘to’ field is closed be the user:
	1) typing on the keyboard when the focus is still on the ‘to’ field
	2) tapping on the ‘your message’ textfield and so changing focus to the ‘your message field’


It was specified that a use should *never* be able to edit the 'to-field' in multiline view. The reasoning behind this was to allow maximum real estate for the auto suggestions that are detailed on page 7. (real estate is very much at a premium on our devices)


> 
> Thanks,
> Mark


feel free to Need-Info me if you want to discuss further

Comment 14

[Steve Chung [:steveck]]

Comment on attachment 759037 [details]
link to pull request

Hi Mark, this patch looks good to me, please squash the commits into one. Having another follow test patch or merging the test patch into current path both works for me.

Comment 15

[Mark Shiao]

landed on master commit# 3f699c44213cab50fdca261bfbd3bc5c4a5552d3

Hi Rick,

Going to leave this one for you to close after you've made your commit.  Let me know if there are any issues with this approach.

Thanks,
Mark

Comment 16

[Rick Waldron [:rwaldron]]

landed on master commit# 2d72e678af4defee7d4079dcdc62e6d5bd509f80

https://github.com/mozilla-b2g/gaia/commit/2d72e678af4defee7d4079dcdc62e6d5bd509f80

Comment 17

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 2d72e678af4defee7d4079dcdc62e6d5bd509f80 to:
v1-train: 4ea1b702212c87eb2a97e78eccae92b8b9ef7578

Comment 18

[Leo]

Hi Ayman,

In multiline-view if user removes all the recipient entries what should be the behavior? In that case also shouldnt we move to single line mode?

please clarify.

Comment 19

[Rick Waldron [:rwaldron]]

(In reply to Leo from comment #18)
> Hi Ayman,
> 
> In multiline-view if user removes all the recipient entries what should be
> the behavior? In that case also shouldnt we move to single line mode?

This is already the behaviour.

Comment 20

[ayman maat :maat]

(In reply to Leo from comment #18)
> Hi Ayman,
> 
> In multiline-view if user removes all the recipient entries what should be
> the behavior? In that case also shouldnt we move to single line mode?
> 
> please clarify.

yes