Closed Bug 883340 Opened 10 years ago Closed 10 years ago

Keyboard keys do not change case (stuck in capital/upper case)


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

Gonk (Firefox OS)
Not set


(Not tracked)



(Reporter: zcampbell, Assigned: mihai)



(Keywords: regression, Whiteboard: [fromAutomation][label:Keyboard & IME])


(2 files)

On master/mc build the keyboard is stuck in upper case mode.

The output from the keyboard is correct but the keys are not re-drawing after the shift key is pressed.

Gaia  46e1ec0547f2a0c1c2b9441a0a07acc10c4e828d
BuildID 20130614031241
Version 24.0a1

1. Start device
2. Load SMS app
3. Tap field to display keyboard
4. All keys are upper-case/shift key does not work
Whiteboard: [fromAutomation][label:Keyboard & IME]
Attached image Screenshot normal state
My observation:
1. Initially, all keys appear in upper-case though when you type, the input characters are lower-case.
2. When you tap the shift key, all the keys are still in upper-case. But the input characters are now in upper-case.

I am able to reproduce this bug in master build in unagi.
(2013.06.16 pvt master build)
  <!-- Mercurial-Information: <project name="mozilla-central" path="gecko" remote="hgmozillaorg" revision="36da3cb92193"/> -->
  <project name="gecko.git" path="gecko" remote="mozillaorg" revision="161d0d64f7baa57bd52220ade7f189fd4e4f0dea"/>
  <project name="gaia.git" path="gaia" remote="mozillaorg" revision="141ed6da339f477523dcc932217fc0ba7a0ea68d"/>

I think the solution could be making the shift key enabled when it is capitalized in the very beginning.
blocking-b2g: --- → leo?
The leo nom doesn't make sense here. This bug is only reproducible on master, not v1-train. You want koi in this case.
Jason, thanks.
blocking-b2g: leo? → koi?
This behavior was added as a performance improvement by the patch for bug 860318 and bug 810306 details the design decision behind it.

Its fix seems to be tracked in bug 875963. I'm not marking it as a duplicate for now since it is not clear if the patch for bug 875963 will fix the behavior or simply create the proper setup for it to be fixed.
Assignee: nobody → mihai
Depends on: 860318, 875963
As far as I know, the all-caps change is not only for performance, but also a UX design decision.

We think we already had a discussion in bug 810306 and in dev-gaia,

Maybe we could try to fix bug 875963 and then ask the UX to re-evaluate this design decision again, but for now, it is not a bug, it's by design.
blocking-b2g: koi? → ---
Closed: 10 years ago
Resolution: --- → DUPLICATE
So performance issues have been mentioned here for switching between lower and uppercase keyboard layouts. But on bug no comment really mentions how large this impact actually is. All what I see is that people mention impacts. Has anyone actually measured those? Also with the fix on bug 875963 the performance should have been improved a lot. Maybe Jan can give us some numbers here.

Also here an excerpt from bug 860318 comment 15 which was done by Josh Carpenter:

> (In reply to Fabrice Desré [:fabrice] from comment #11)
> > Is it expected that the keyboard only displays UPPERCASE letters even when
> > entering lowercase ones? That's pretty broken imho, so I'm backing this out.
> > 
> >
> > 447cdaa4656d6a830f5bd129be0ac0c755fa6153
> This is intentional. For prior art comparison, try iOS vs Android.

The question is if all what Apple does is good. But as of now we have a totally different user base. The question is how they feel about this change. We haven't released 1.2 yet, so we might lack feedback on that. But once that happened I wonder how our user base on 1.2 will react. 

Also I agree that this is not a dupe. Main reason is that this bug is not about having capital letters only, but is requesting exactly the opposite. This bug is about to get back the upper/lowercase keyboard. So marking as regression by bug 860318 (compared to v1.1) and adding dependency. If we really cannot go this way, it should become at least a Wontfix.

But before we do this, I think what would be really helpful is to re-check which performance impacts we really have as of today and if it really makes sense to always call out those impacts when there is an upcoming discussion about which keyboard layout we support. As mentioned above, so far I don't see any numbers for that.
Blocks: 810306
Resolution: DUPLICATE → ---
In reply to Rudy Lu [:rudyl] from comment #8)
> Maybe we could try to fix bug 875963 and then ask the UX to re-evaluate this
> design decision again, but for now, it is not a bug, it's by design.

Both dependencies have been fixed. So that should indeed be re-evaluated. Which performance loss do we still experience?
We have gone through a discussion on this topic during a keyboard workshop, and this (keep all keys shown as uppercase) is still the final decision for keyboard UX.

Dear Mike,

Could you please attach the keyboard spec here and maybe share the rationale behind this design here or on #dev-gaia?

Flags: needinfo?(mtsai)
Hi guys,
As far as I know. This topic has been discussed for a long time. There is no right and wrong answer on it. As we are moving into next version keyboard design. This issue also raised and noticed. We are studying and doing UX research over it and will update you guys on the result. Thank you.

Currently most Android device use lower case as default while Apple and BlackBerry use uppercase default.
Flags: needinfo?(mtsai)

Just wanted to add my point of view.
IMHO, as OEM, I really think that showing the keyboard always in uppercase mode is quite confusing for a user. 

I see a particular confusing use case when your are typing a password; since the characters are hidden, the user may doubt about if he is typing the correct password.

I see quite more user-friendly the way Android implements this, compared to Apple and BB.
Has the rationale for this change been shared anywhere? I would love to read it.
As UX suggests above, a final decision has been made here. We'll do more research, but the current decision still stands to use uppercase only.
Closed: 10 years ago10 years ago
Resolution: --- → INVALID
I know the final decision has been made for this one, but still I want to point out that this design is not that user-friendly for inputting characters in the password field where all the password are marked by *
let me also add, that from end user perspective, this is confusing to not be able switch between capital and small letters. Specifically for the passwords.
This bug is not invalid.  It's a duplicate.  The reason we have uppercasing on the keyboard is due to a performance reason :
Having used v1.1 and v1.2, I have notice no performance difference. Are there performance test results somewhere that would justify this change?
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #31)
> This bug is not invalid.  It's a duplicate.  The reason we have uppercasing
> on the keyboard is due to a performance reason :

Well, this bug is a result of the change in bug 860318, and has been filed as such. So it cannot be a duplicate, because it requests to revert this change. Therefor the decision made here is still invalid, even there might still be questions to re-check that in the future.
Surely this is not INVALID, since, indeed, the key caps always show uppercase glyphs as on iOS but unlike Android. If it is this way due to performance or UX design, surely the appropriate resolution would be WONTFIX.

(In reply to Rudy Lu [:rudyl] from comment #8)
> As far as I know, the all-caps change is not only for performance, but also
> a UX design decision.

That's unfortunate. Was this based on aesthetics (uppercase makes the keyboard more beautiful) or on usability testing? At least considering myself as an anecdotal single data point, I find the Android keyboard more usable, because it's easier to know if I have it in the right state for the next letter I want to type.
As someone who uses Firefox OS daily on my primary device I have to agree with the feedback from the partner here and other users the experience is just inferior.
You need to log in before you can comment on or make changes to this bug.