954712 - [Messages] Hide subject field when input is empty and user taps backspace

Status: VERIFIED FIXED

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

Description

[isabelrios]

12/30 1.3 Build:
Gecko-3820ecd
Gaia-01e9da4

STR
Create a new message
Add a subject (Message '...' option -> Add subject)
Write something into the Subject field
Then remove what has been written, character by character using the delete button in the keyboard.

EXPECTED
According to latest wfs: FFOS_MessageApp_V1.3_20131125_V8.0.pdf (https://mozilla.app.box.com/s/0u4jt353ei9ov2c150ip/1/1170795225/11918301182/1) page 6 screen 4, subject can be removed using the given option or when all the characters in subject field are removed:
User removes subject field by either:
- Selecting options menu in top right hand corner, or
- Selecting the delete button in the keyboard. if all the text is removed from the subject field and the user selects delete on the keyboard the subject field is removed. 

ACTUAL
Using the delete button in the keyboard it is possible to delete all the characters in the subject field, but the subject field is not removed when all the characters have been removed and the delete key is pressed again.

Comment 1

[Rick Waldron [:rwaldron]]

The spec from page 6, screen 4:

> User removes subject field by either:
> - Selecting options menu in top right hand corner, or
> - Selecting the delete button in the keyboard. if all the text is removed from the subject field and the user selects > delete on the keyboard the subject field is removed

I'm not sure this is a good idea; consider the following: 

1. Type a subject followed by a message
2. Then decide to change the subject entirely.
3. Delete all characters in the subject to type out the new subject.

Expected: 
Subject field stays available for me to type in (this is what currently happens)

Actual (according to spec): 
Subject field disappears with no explanation and I now have to use the option menu to add it back.

Comment 2

[Noemí Freire (:noemi)]

(In reply to Rick Waldron [:rwaldron] from comment #1)
> The spec from page 6, screen 4:
> 
> > User removes subject field by either:
> > - Selecting options menu in top right hand corner, or
> > - Selecting the delete button in the keyboard. if all the text is removed from the subject field and the user selects > delete on the keyboard the subject field is removed
> 
> I'm not sure this is a good idea; consider the following: 
> 
> 1. Type a subject followed by a message
> 2. Then decide to change the subject entirely.
> 3. Delete all characters in the subject to type out the new subject.
> 
> Expected: 
> Subject field stays available for me to type in (this is what currently
> happens)
> 
> Actual (according to spec): 
> Subject field disappears with no explanation and I now have to use the
> option menu to add it back.

ni to UX to confirm the expected behavior here. Thanks!

Comment 3

[Joe Cheng [:jcheng] (please needinfo)]

triage: not a blocker

Comment 4

[ayman maat :maat]

removal of subject field using delete is designed as accelerator for the user saving them from having to remove via the menu in the top right hand corner. Its lack of implementation should not be a blocker however because, as stated, the user can still remove subject using the menu field.

in reply to comment 2 expected behaviour is:

User removes subject field by either:
- Selecting options menu in top right hand corner, or
- Selecting the delete button in the keyboard when cursor focus is in the subject field *and* the subject field contains no text. Therefore if all the text is removed from the subject field and the user selects delete on the keyboard the subject field is removed.

Comment 5

[Rick Waldron [:rwaldron]]

(In reply to ayman maat :maat from comment #4)
> removal of subject field using delete is designed as accelerator for the
> user saving them from having to remove via the menu in the top right hand
> corner. Its lack of implementation should not be a blocker however because,
> as stated, the user can still remove subject using the menu field.
> 
> in reply to comment 2 expected behaviour is:
> 
> User removes subject field by either:
> - Selecting options menu in top right hand corner, or
> - Selecting the delete button in the keyboard when cursor focus is in the
> subject field *and* the subject field contains no text. Therefore if all the
> text is removed from the subject field and the user selects delete on the
> keyboard the subject field is removed.

Ok, this makes sense—thanks for clarifying!

Comment 6

[Rick Waldron [:rwaldron]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/15118

Comment 7

[Julien Wajsberg [:julienw]]

Comment on attachment 8357281 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/15118

I think the main use case is done but I'm concerned that sendButton's properties are set both in compose.js and thread_ui.js. Maybe it's time to do some minimal refactoring before doing this patch, or in this patch? What do you think?

Comment 8

[Rick Waldron [:rwaldron]]

Updated the PR, but there was another question

Comment 9

[Rick Waldron [:rwaldron]]

Comment on attachment 8357281 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/15118

new bug filed for the "has-counter" display issue: https://bugzilla.mozilla.org/show_bug.cgi?id=959360

Comment 10

[Julien Wajsberg [:julienw]]

Comment on attachment 8357281 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/15118

Added a comment about the "keeping backspace pressed" behavior. I really think we should prevent this.

Comment 11

[Julien Wajsberg [:julienw]]

Filed bug 960946 to fix the wrong event behavior in Firefox OS.

Comment 12

[Julien Wajsberg [:julienw]]

Comment on attachment 8357281 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/15118

r=me with the patch rebased, the lints fixed, the comments added, the logs removed, the test comments addressed, and a green travis :)

Comment 13

[Rick Waldron [:rwaldron]]

All the things addressed, travis is green

https://github.com/mozilla-b2g/gaia/commit/fc15e10e508363ffa98d6c9c075582ca8c2392e8

Comment 14

[isabelrios]

This is working as expected on master (01/24) build:
Gecko-85b8bb0
Gaia-4699d23

Comment 15

[Noemí Freire (:noemi)]

(In reply to Isabel Rios [:isabel_rios] from comment #14)
> This is working as expected on master (01/24) build:
> Gecko-85b8bb0
> Gaia-4699d23

great news!

Rick, Julien, Could we ask for "approval‑gaia‑v1.3?" for this patch?. Thanks!

Comment 16

[Julien Wajsberg [:julienw]]

Noemi, I think we need bug 960946 fixed to have a consistent behavior.

Here is a STR to reproduce what I'm saying:
* open a thread
* add a subject line
* type some text
* press backspace and keep it pressed

Expected:
* the subject line is not removed unless we release backspace and press it again

Actual:
* the subject line is removed

That's why I think it's better to not uplift this to 1.3, and have bug 960946 fixed for 1.4.

What do you think Noemi ? Same question for Ayman ?

Comment 17

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #16)
> Noemi, I think we need bug 960946 fixed to have a consistent behavior.
> 
> Here is a STR to reproduce what I'm saying:
> * open a thread
> * add a subject line
> * type some text
> * press backspace and keep it pressed
> 
> Expected:
> * the subject line is not removed unless we release backspace and press it
> again
> 
> Actual:
> * the subject line is removed
> 
> That's why I think it's better to not uplift this to 1.3, and have bug
> 960946 fixed for 1.4.
> 
> What do you think Noemi ? Same question for Ayman ?

Julien is correct in the flow he outlines here. Removal of subject should be an extra tap on delete in isolation. It would be a usability issue to hold down backspace, remove all the text and remove the subject field in one action.

I would be happy to wait for 960946 if this is Julien's advice.

Comment 18

[Noemí Freire (:noemi)]

> Julien is correct in the flow he outlines here. Removal of subject should be
> an extra tap on delete in isolation. It would be a usability issue to hold
> down backspace, remove all the text and remove the subject field in one
> action.
> 
> I would be happy to wait for 960946 if this is Julien's advice.

Fine by  me too. Thanks!

Comment 19

[Loli (:lolimartinezcr)]

Tested and working
Device: Hamachi
1.4
Build ID: 20140304082349
Platform version 30.0a1
Gecko: ffe5883
Gaia:71f78f77

Tested and NOT working
1.3
Build ID:20140304091708
Platform version 28.0
Gecko: 21d6a90
Gaia: 242e477

Comment 20

[Loli (:lolimartinezcr)]

(In reply to Loli from comment #19)
> Tested and working
> Device: Hamachi
> 1.4
> Build ID: 20140304082349
> Platform version 30.0a1
> Gecko: ffe5883
> Gaia:71f78f77
> 
> Tested and NOT working
> 1.3
> Build ID:20140304091708
> Platform version 28.0
> Gecko: 21d6a90
> Gaia: 242e477

Please, i need know if this bug has to be resolved in 1.3.

Comment 21

[Maria Angeles Oteo (:oteo)]

(In reply to Loli from comment #20)
> (In reply to Loli from comment #19)
> > Tested and working
> > Device: Hamachi
> > 1.4
> > Build ID: 20140304082349
> > Platform version 30.0a1
> > Gecko: ffe5883
> > Gaia:71f78f77
> > 
> > Tested and NOT working
> > 1.3
> > Build ID:20140304091708
> > Platform version 28.0
> > Gecko: 21d6a90
> > Gaia: 242e477
> 
> Please, i need know if this bug has to be resolved in 1.3.

It's not resolved in v1.3, it's not flagged with 1.3+ and has not been requested 1.3 approval to uplift it so you don't need to verify it in that branch.

Comment 22

[Maria Angeles Oteo (:oteo)]

Besides in comment 16, Julien explains that it's better not to uplift it to v1.3 and all agreed :)

Comment 23

[Noemí Freire (:noemi)]

already answered so clearing the needinfo request

Comment 24

[Julien Wajsberg [:julienw]]

(In reply to Maria Angeles Oteo (:oteo) from comment #22)
> Besides in comment 16, Julien explains that it's better not to uplift it to
> v1.3 and all agreed :)

Note that bug 960946 won't be fixed for 1.4 either :(