822959 - [Clock] Deleting in the alarm label will reprint the label you deleted

Status: VERIFIED FIXED

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

Description

[Tony Chung [:tchung]]

Attachment: screenshot

Create a new alarm label, but hitting backspace in the textbox until the cursor has removed all the text.  Once the cursor gets to the first character, the label reappears.

See screenshot

Repro:
1) install 20121218070200 unagi nightly
2) launch clock app
3) create an alarm
4) put the cursor in "label", and delete the existing label there by hitting backspace (eg. "Alarm")
5) once the cursor deletes everything back to the first cursor position, the label reappears.

Expected:
- deleting a label should remain deleted

ActuaL:
- deleting the label all the way will show the label again.

Comment 1

[John Shih]

I don't think this is a bug, it's a mechanism to prevent from creating an alarm with empty label
after delete the original label and enter an arbitrary letter, the default label (the one reappears) will disappear

Comment 2

[John Shih]

but we can take it as a polish, maybe displays with gray text will be better
Tony, what do you think?

Comment 3

[[e-mail], [e-mail]]

I agree with John's suggestion. There is a placeholder="Alarm" in the input tag of label. We can reference the spec. of Clock APP.
(https://wiki.mozilla.org/Gaia/Clock#Requirements)

Set alarm label option:

    Default string is "Alarm", or overwrite with your own label 

Hi Josh,
How do you think for the issue? We also need your suggestion.

Comment 4

[Tony Chung [:tchung]]

if it's supposed to be instructional text, then i agreewith comment 2, making the text color greyed out.  it needs to seem non-editable, instead of seemingly the pre-populated text.

Comment 5

[Josh Carpenter [:jcarpenter]]

Good catch.

We should resolve this by making "Alarm" the field's hint text, in gray. 
The hint text disappears as soon as the user focuses the field and starts to type a new name.
If the user does not enter a name, or deletes all characters of an existing name, the "Alarm" hint reappears
If user saves their changes (taps "Done") while the field is blank (with "Alarm" hint visible), then "Alarm" becomes the alarm's label.

Does that make sense to everyone? Is that realistic to implement for v1?

Comment 6

[Misty Byrd]

This issue repros in B2G: Gaia, OS version 1.0.0, Build ID: 20121217070202
Test Case #1775

Comment 7

[Misty Byrd]

This issue repros in Ungia, build 20130104070203 v.1.0. The "Alarm" the field's hint text, is not gray.

Comment 8

[[e-mail], [e-mail]]

(In reply to Josh Carpenter [:jcarpenter] from comment #5)
> Good catch.
> 
> We should resolve this by making "Alarm" the field's hint text, in gray. 
> The hint text disappears as soon as the user focuses the field and starts to
> type a new name.
> If the user does not enter a name, or deletes all characters of an existing
> name, the "Alarm" hint reappears
> If user saves their changes (taps "Done") while the field is blank (with
> "Alarm" hint visible), then "Alarm" becomes the alarm's label.
> 
> Does that make sense to everyone? Is that realistic to implement for v1?
I vote the behavior.
And it's a realistic solution for v1.

Comment 9

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

(In reply to Josh Carpenter [:jcarpenter] from comment #5)
> Good catch.
> 
> We should resolve this by making "Alarm" the field's hint text, in gray. 
I totally agree with this.

> The hint text disappears as soon as the user focuses the field and starts to type a new name.
If we use a placeholder (I think we should) for the 'hint text' the placeholder disappears when the user write the first symbol not when the user focuses the field. That means that we just put the actual value only when we edit the alarm.

> If the user does not enter a name, or deletes all characters of an existing name, the "Alarm" hint reappears.
Again, we don't need to set the value="Alarm" we have a placeholder, right :)

> If user saves their changes (taps "Done") while the field is blank (with "Alarm" hint visible), then "Alarm" becomes the alarm's label.
>
> Does that make sense to everyone? Is that realistic to implement for v1?
I think this is important UX issues and we need to land this for v1.

Ian Liu: if you need help with implementation I can help :)

Comment 10

[[e-mail], [e-mail]]

(In reply to Pavel Ivanov [:ivanovpavel] from comment #9)
> (In reply to Josh Carpenter [:jcarpenter] from comment #5)
> > Good catch.
> > 
> > We should resolve this by making "Alarm" the field's hint text, in gray. 
> I totally agree with this.
> 
> > The hint text disappears as soon as the user focuses the field and starts to type a new name.
> If we use a placeholder (I think we should) for the 'hint text' the
> placeholder disappears when the user write the first symbol not when the
> user focuses the field. That means that we just put the actual value only
> when we edit the alarm.
It's true. This is a native behavior of placeholder.
Josh, do you agree with the native behavior of HTML attribute placeholder?
> 
> > If the user does not enter a name, or deletes all characters of an existing name, the "Alarm" hint reappears.
> Again, we don't need to set the value="Alarm" we have a placeholder, right :)
(Also native behavior :P)
> 
> > If user saves their changes (taps "Done") while the field is blank (with "Alarm" hint visible), then "Alarm" becomes the alarm's label.
> >
> > Does that make sense to everyone? Is that realistic to implement for v1?
> I think this is important UX issues and we need to land this for v1.
> 
> Ian Liu: if you need help with implementation I can help :)

Pavel,
I will fix the issue when the solution is confirmed.
Thank you.

Comment 11

[Josh Carpenter [:jcarpenter]]

(In reply to Ian Liu [:ianliu] from comment #10)
> (In reply to Pavel Ivanov [:ivanovpavel] from comment #9)
> > (In reply to Josh Carpenter [:jcarpenter] from comment #5)
> > > Good catch.
> > > 
> > > We should resolve this by making "Alarm" the field's hint text, in gray. 
> > I totally agree with this.
> > 
> > > The hint text disappears as soon as the user focuses the field and starts to type a new name.
> > If we use a placeholder (I think we should) for the 'hint text' the
> > placeholder disappears when the user write the first symbol not when the
> > user focuses the field. That means that we just put the actual value only
> > when we edit the alarm.
> It's true. This is a native behavior of placeholder.
> Josh, do you agree with the native behavior of HTML attribute placeholder?
 
Yes, that's fine :)

Comment 12

[amiller]

UCID: clock-015
https://moztrap.mozilla.org/results/case/61296/

Comment 13

[[e-mail], [e-mail]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7609

Pointer to Github pull-request

Comment 14

[[e-mail], [e-mail]]

Comment on attachment 702158 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7609

Set a color 'gray' for the placeholder of alarm label.

Tim,
Could you please help to review the pr?

Comment 15

[[e-mail], [e-mail]]

Comment on attachment 702158 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7609

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): No specific color for placeholder.
User impact if declined: Improve UX.
Testing completed: Yes.
Risk to taking this patch (and alternatives if risky): None.

Comment 16

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://github.com/mozilla-b2g/gaia/commit/92e745886249642a3363cad10428aa91b26f2344

Comment 17

[sarath v s]

The conclusion for this bug doesnt seem appropriate. 
Comment-5 from Josh Carpenter looks like an appropriate UX scenario. This will make the UX look very similar to the UX of contact application. In contact application, the default text is a hint text and it disappears when the input is focused. If the input is left blank, the default text will be taken as the input value. The behaviour of alarm input should also be simalar. I have made the changes for this requirement.
I believe this bug should be reopened for further discussions if required.
Please check the Github pullrequest URL: https://github.com/mozilla-b2g/gaia/pull/7707

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to sarathbalank from comment #17)
> The conclusion for this bug doesnt seem appropriate. 
> Comment-5 from Josh Carpenter looks like an appropriate UX scenario. This
> will make the UX look very similar to the UX of contact application. In
> contact application, the default text is a hint text and it disappears when
> the input is focused. If the input is left blank, the default text will be
> taken as the input value. The behaviour of alarm input should also be
> simalar. I have made the changes for this requirement.
> I believe this bug should be reopened for further discussions if required.
> Please check the Github pullrequest URL:
> https://github.com/mozilla-b2g/gaia/pull/7707

Please file another bug for that. We don't reopen bugs with landed code (unless it is being backout'd)

Comment 19

[Askeing Yen[:askeing][:fyen]]

Gaia:     6c53dfd2e5d60393f6a57e9e1a4b5af6a3d6a783
Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18/rev/2226f181c8c2
BuildID   20130126070202
Version   18.0

Verified base on comment #5.

Comment 21

[Leo]

Attachment: Pointer to pull request

Default Text in Alram label is an hint text.Please check the attached patch.
https://github.com/mozilla-b2g/gaia/pull/8128