Closed Bug 796543 Opened 12 years ago Closed 12 years ago

[vkb] Uppercase appears whenever a text field is focused

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia
Type:
defect

Tracking

(blocking-basecamp:+)

Status:
VERIFIED FIXED
Project Flags:
blocking-basecamp +

People

(Reporter: ghtobz, Assigned: djf)

References

Details

(Whiteboard: [label:Keyboard & IME][label:mentored][LOE:M]) 

[GitHub issue by mounirlamouri on 2012-08-27T14:22:34Z, https://github.com/mozilla-b2g/gaia/issues/3856]
It should only be the case when a field is focused and the value is currently the empty string.

I don't know how the vkb decides to show uppercase or not. Given that it appears in more than one app, I assume it's a vkb issue.
[GitHub comment by nhirata on 2012-08-27T16:18:33Z]
I forgot to write a bug on this on a similar issue.  If you go out of the field and dismiss the keyboard and place the focus back in, you still get an Uppercase letter.  

It was part of the spec to have the first character capitalized.  https://wiki.mozilla.org/Gaia/System/Keyboard:  "Auto capitalize beginning of sentences and names." 

I think we should be a little more intelligent in terms of when we show the capitalization.
[GitHub comment by autonome on 2012-09-14T17:01:36Z]
Inserting capital letters in the middle/end of words on re-focus seems like a broken keyboard. Marking blocking+.
[GitHub comment by autonome on 2012-09-14T20:31:56Z]
Marking medium effort - @vingtetun said a proper fix will require platform changes.
[GitHub comment by autonome on 2012-09-25T03:42:35Z]
@RudyLu do you know what's involved to fix this? if it requires platform changes, we should get those filed as soon as possible.
IIRC this has been modified by Alexandre Lissy, it makes sense on multi-line text inputs such as messages. I’d suggest not to auto-capitalize single-line inputs.

Is there a standard property to control this behavior more sharply? How does it work on Android?
Hmm, we probably should use the `inputmode' property here.
www.whatwg.org/specs/web-apps/current-work/#attr-inputmode/

See bug 746142.
Convert vkb to use input mode is bug 796544.
Expose selection/cursor position through mozKeyboard is bug 796080.

If we are not going to fix these to dependent bugs then we should just disable the current stupid-uppercase-everything behavior.

Spell check/auto-complete is also affected ... CCing :djf
Depends on: 796080, 796544
Tim, thanks for cc'ing me on this.

Kaze, the inputmode attribute looks perfect.

Until we have true inputmode support, how about this behavior:

For textareas, if they're empty, we automatically capitialize.

But for other elements, or when focusing an textarea that is not empty we do not capitalize.

If that sounds like a good plan, 

We will still capitalize after space-space (which turns into period space) however.

I'm kind of deep in the keyboard code right now, and the behavior I describe will be easy to do, I think.

And it sounds like a good plan to me, so I'm assigning this to myself.
Assignee: nobody → dflanagan
(In reply to David Flanagan [:djf] from comment #10)
> Tim, thanks for cc'ing me on this.
no worries.

> 
> Kaze, the inputmode attribute looks perfect.
> 
> Until we have true inputmode support, how about this behavior:
> 
> For textareas, if they're empty, we automatically capitialize.
> 
> But for other elements, or when focusing an textarea that is not empty we do
> not capitalize.

That sounds like a temporary solution to de-dependent this bug with other bugs. Are we NOT going to support inputmode for v1?
Tim,

inputmode support would be great, and Dietrich linked above to a bug that is specific to inputmode.

So I interpret this bug as "just fix the broken behavior".  I would guess that inputmode support is not a blocker, but this bug is.

Meanwhile, I've discovered that I can't tell in the keyboard whether the input field is empty or not.  forms.js sends the element.value to mozKeyboard, and mozKeyboard looks like it puts that into the onfocuschange event, but it is not there when the event is delivered.  So I think that without a platform change, all I can do is turn off automatic capitalization.  And that means that I'm not going to have a patch to attach here tonight.
Well the reason the element.value wasn't getting through from forms.js to the focuschange event is that I was testing with an old b2g-desktop from before the value property got added to the event!

Unfortunately, I do not have a new enough working environment to test on tonight, but I've created a pull request with a proposed fix at https://github.com/mozilla-b2g/gaia/pull/5670

I'm posting this now, without careful testing because this is a blocking bug and because I'm going to be on PTO tomorrow.  If anyone wants to review, test, and land it, that would be awesome!
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #9)
> If we are not going to fix these to dependent bugs then we should just
> disable the current stupid-uppercase-everything behavior.

This feature has been provided by a volunteer, let’s not give him the impression we don’t respect his work by using inappropriate adjectives please.

I agree we have to do something because this behavior is causing “bugs”, e.g. when typing login/passwords.

(In reply to David Flanagan [:djf] from comment #10)
> Until we have true inputmode support, how about this behavior:
> 
> For textareas, if they're empty, we automatically capitialize.
> 
> But for other elements, or when focusing an textarea that is not empty we do
> not capitalize.

That makes sense to me. If Tim doesn’t review your patch in the next few hours, I’ll review it later in the afternoon (Paris time).
(In reply to Fabien Cazenave [:kaze] from comment #14)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #9)
> > If we are not going to fix these to dependent bugs then we should just
> > disable the current stupid-uppercase-everything behavior.
> 
> This feature has been provided by a volunteer, let’s not give him the
> impression we don’t respect his work by using inappropriate adjectives
> please.
> 

My apologies. I vaguely remember I am the one who merge that pull request so I am partly responsible to this bug too :-(

> I agree we have to do something because this behavior is causing “bugs”,
> e.g. when typing login/passwords.
> 
> (In reply to David Flanagan [:djf] from comment #10)
> > Until we have true inputmode support, how about this behavior:
> > 
> > For textareas, if they're empty, we automatically capitialize.
> > 
> > But for other elements, or when focusing an textarea that is not empty we do
> > not capitalize.
> 
> That makes sense to me. If Tim doesn’t review your patch in the next few
> hours, I’ll review it later in the afternoon (Paris time).

Go right ahead if inputmode is not a blocker and we really need to fix this blocker bug.
Priority: -- → P2
Priority: P2 → --
Fixed in https://github.com/mozilla-b2g/gaia/pull/6007
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Priority: -- → P3
Reviewed and verified on build ID: 20121231070201
Device -"Unagi"
OS -"Gonk"
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.