[B2G][Cost Control][Data Alert] Full keyboard instead of numpad is present when inputting a Data Alert limit in the Usage app.

VERIFIED FIXED

Status

Firefox OS
Gaia::Cost Control
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: Marty, Assigned: mnjul)

Tracking

({regression})

unspecified
ARM
Gonk (Firefox OS)
regression

Firefox Tracking Flags

(b2g-v2.0 unaffected, b2g-v2.1 verified)

Details

Attachments

(4 attachments)

(Reporter)

Description

4 years ago
Created attachment 8473956 [details]
logcat-Data_Alert.txt

Description:
When setting up a Data Alert limit in the Usage app, the user is presented with a full keyboard, and is able to input letters and special characters, instead of only numbers.

Note: In 2.0, the user is presented with just a numpad.


Repro Steps:
1) Update a Flame to 20140815040204
2) Open the Usage app and set up a Data Alert
3) Select the data usage limit to change the value


Actual:
The user is presented with a full keyboard.


Expected:
The user is only given a numpad.

Environmental Variables:
Device: Flame Master
Build ID: 20140815040204
Gaia: 9979fccc6321be72cd17370f3a20c65bc376af33
Gecko: c9f8cc9ce89c
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

This occurs on both 319MB and 512MB memory.

Keywords: Cost Control, Data Alert, Usage, keyboard, 


Repro frequency: 100%
See attached: screenshot, logcat
(Reporter)

Comment 1

4 years ago
Created attachment 8473958 [details]
Data_Alert_Screenshot.png

This issue does NOT occur on Flame 2.0 at either 319MB or 512MB.
A numpad is presented to the player.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140815000200
Gaia: 295c7f50707372e5af6d8e83148d2d970076dfd6
Gecko: 879c5208084f
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
(Reporter)

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
[Blocking Requested - why for this release]:
Regression with the keyboard app in Data Usage app.

Requesting a window
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Keywords: regression, regressionwindow-wanted
QA Whiteboard: [QAnalyst-Triage+]
QA Contact: pcheng
b2g-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20140814055307
Gaia: f09ae1c020d88bb63f62ac499fe557700e8bb5fc
Gecko: 6e5fc83fc7d1
Version: 34.0a1 (2.1 Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20140814063807
Gaia: 23b85ffc45f8ffbea0299c9d17f4012646a5e533
Gecko: f677de9f17fb
Version: 34.0a1 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First broken gecko & last working gaia - issue does NOT repro
Gaia: f09ae1c020d88bb63f62ac499fe557700e8bb5fc
Gecko: f677de9f17fb

First broken gaia & last working gecko - issue DOES repro
Gaia: 23b85ffc45f8ffbea0299c9d17f4012646a5e533
Gecko: 6e5fc83fc7d1

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/f09ae1c020d88bb63f62ac499fe557700e8bb5fc...23b85ffc45f8ffbea0299c9d17f4012646a5e533

Caused by bug 1024298.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
broken by bug 1024298 ? can you take a look John?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(jlu)
Well, the issue you describe is a specified UX change in bug 1024298. If Usage app's UX wants the numpad for that field, you can add x-inputmode="digit" to bring back the numpad.
Flags: needinfo?(jlu)
NI to Carrie to get someone from Systems-Platform / Cost Control / Keyboard UX to weigh in on this bug and the intended design for which keyboard the usage app should bring up
Flags: needinfo?(cawang)

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
ni? Omega who's in charge of Keyboard.
Flags: needinfo?(cawang) → needinfo?(ofeng)
That's a keyboard UX change on number input.
A number input should accept any kind of characters. (e.g. Desktop Firefox, iOS Safari, etc)
Flags: needinfo?(ofeng)
Jason - this seems like a Resolved-Invalid - just wanted to check with you before closing to make sure I'm interpreting this correct.
Flags: needinfo?(jsmith)
Something doesn't seem right here - this is essentially arguing to introduce worse UX than what we have currently, as this risks users providing input characters that don't accurately represent what can be accepted in a particular input field. I think we need to revisit the design decision here.
Flags: needinfo?(jsmith) → needinfo?(firefoxos-ux-bugzilla)

Comment 11

4 years ago
Flagging Mike to review while Omega is on PTO.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(mtsai)

Comment 12

4 years ago
Created attachment 8476578 [details]
pincodepad.png

In this case, I suggest we use pin code pad instead of numpad UI. Because for user to set data usage limit, pin code pad should be good enough. Since users may not need to use symbols or even decimal for setting up GB/MB value.

Please see attachment pincodepad.png for pin code pad.

----------------------------------------------------------------------------------
For the same issue in current phone industry, there are mainly two approaches. One is using a view like we do, another is making a transformed numpad that not only allow users to type in numbers but also keywords.(Usually a 4x4 pad transformed from 3x4 pin code pad to provide more function keys such as symbols and space key) Using current UI, the former solution, was a decision made by UX team due to two reasons. One is that even for our desktop browser or iOS Safari, a number input supports any kind of characters. Another is that UX team wants to use what is available in the keyboard UI so we can keep our keyboard layout simple instead of create another new design. And this actually went through a debate. Just give a history/story background.
Flags: needinfo?(mtsai)

Comment 13

4 years ago
Comment 12 is just a suggestion for this reticular situation, but may not apllicable to all.
Due to QA's feedback and concern on the change, UX team will reopen this case and evaluate the issue. We will feedback next Monday and hopefully it's a solution we all agree. Tanak you.
We have the following two options:
1) Keep the old design: 3x4 with some symbols/alternatives .,-
2) Use the new design: the symbol panel 1 (with more number related symbols than option 1. See this for reference: http://en.wikipedia.org/wiki/Decimal_mark#Examples_of_use )
Rudy, could you help contact l10n team to evaluate which symbols are necessary for number inputs? Maybe we can use option 1) and add some more symbols as alternatives.
Let's finish this before this Wednesday.
Flags: needinfo?(rlu)
According to http://en.wikipedia.org/wiki/Decimal_mark#Examples_of_use and Android implementation, it seems we should add [Space] key to 3 x 4 number panel.

Pike, Delphine, do you know who could help review the above proposal and comment 14 and firm the design around number panel?

Thanks.
Flags: needinfo?(rlu)
Flags: needinfo?(lebedel.delphine)
Flags: needinfo?(l10n)

Comment 16

4 years ago
I think there are two different questions here:

Which keys do I need to input a number, float or integer?

How should that number be shown to the user?

Given how hard it is to parse a number out of local context (and even within), I'd restrict the keys to number literals and one key for decimal sep, which gets disabled if pressed once. I'd make the decimal localizable.

Spot checking Bengali for input on how important localized number glyphs are, MAK?

Showing the numbers in the preferred layout sounds like a second step.
Flags: needinfo?(lebedel.delphine)
Flags: needinfo?(l10n)
Let's revert to the old design (3x4 number pad) for now. When we have more information from l10n team, we can add keys as alternatives to that number pad.
I've also update the spec in bug 983043 to reflect this decision.
(In reply to Omega Feng [:Omega] [:馮於懋] from comment #17)
> Let's revert to the old design (3x4 number pad) for now. When we have more
> information from l10n team, we can add keys as alternatives to that number
> pad.
> I've also update the spec in bug 983043 to reflect this decision.

Comment 0 is not reproducible in latest Gaia. Per comment 17 I'm resolving the bug as invalid.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
Maybe a works for me is best suited.
Resolution: INVALID → WORKSFORME
No, this should be FIXED by revert bug 1024298.
Resolution: WORKSFORME → FIXED
Assignee: nobody → jlu
blocking-b2g: 2.1? → ---
status-b2g-v2.1: affected → fixed

Comment 21

4 years ago
This issue has been verified successfully on Flame2.1.
Reproducing rate: 0/5
See attachment: Verify_Flame_Numberkeyboard.mp4

Flame2.1 build version:
Gaia-Rev        38e17b0219cbc50a4ad6f51101898f89e513a552
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a
Build-ID        20141205001201
Version         34.0
Status: RESOLVED → VERIFIED
status-b2g-v2.1: fixed → verified

Comment 22

4 years ago
Created attachment 8532988 [details]
Verify_Flame_Numberkeyboard.MP4
You need to log in before you can comment on or make changes to this bug.