New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 855812 link

Starred by 12 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 6
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Onscreen keyboard capitalizes every new word.

Reported by robwatki...@gmail.com, Jun 23 2018

Issue description

Steps to reproduce the problem:
1. Bring up onscreen keyboard
2.Type a few words 
3. Each new word is capitalized.

What is the expected behavior?
Capitalizes every new word typed 

What went wrong?
It's always done this since I bought my first Chromebook in March. It's done it on 2 different Chromebook convertibles I own.

Did this work before? No 

Chrome version: 68.0.3440.33  Channel: beta
OS Version: 
Flash Version:
 
Labels: Needs-triage-Mobile
Labels: -OS-Android Triaged-Mobile OS-Chrome
The issue seems to be related to OS-Chrome. Hence, adding appropriate OS label for further triaging.

Thanks...!!
Components: -UI UI>Input>VirtualKeyboard

Comment 4 by dymp...@gmail.com, Jun 29 2018

Observation.

1. Turn on Auto-correction. When you type or gesture type and continue the next word, everything is fine. It will  auto add a space between the words.

But, if you hit the space bar or backspace/delete X, it will auto capitalize the next word. Selecting or not the auto-capitalization setting does not change the behavior.

2. If you turn off Auto-correction, it will also make all other functions unusable ie double space to type period, swipe gesture and gesture typing.


Comment 5 by dymp...@gmail.com, Jun 29 2018

Comment 4 is about the onscreen keyboard while in laptop mode.

When in tablet mode, the Android keyboard does not have this issue. 

I can reproduce on both Minnie and Caroline on Beta 68.0.3440.40

Google Chrome	68.0.3440.40 (Official Build) beta (32-bit)
Revision	7dc48310bd688ba7c1823280f55a153683fb503a-refs/branch-heads/3440@{#521}
Platform	10718.34.0 (Official Build) beta-channel veyron_minnie
Firmware Version	Google_Veyron_Minnie.6588.237.0
ARC	4860283
JavaScript	V8 6.8.275.14
Flash	30.0.0.127 /opt/google/chrome/pepper/libpepflashplayer.so
User Agent	Mozilla/5.0 (X11; CrOS armv7l 10718.34.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.40 Safari/537.36


Labels: Hotlist-ConOps-CrOS
Getting this issue on Pixelbook on stable. Only affects touch keyboard when in Android apps, not Chrome and Is Very Very Very Annoying Because I Have To Hit Shift Before Each Word, Please Fix ASAP.
Status: Available (was: Unconfirmed)
Can reproduce on Chrome 69.0.3497.0 on the Evernote Android app.
Owner: yhanada@chromium.org
Status: Assigned (was: Available)
I dug around the code. Could it be because we are returning NONE in [1]? I think if we return NONE, IME thinks that the autocapitalization is SENTENCE [2]. Although I'm not sure why this doesn't repro in other apps like the play store search box.

Hi Hanada-san, could you please take a look at this?

[1] https://cs.chromium.org/chromium/src/components/arc/ime/arc_ime_service.cc?l=480
[2] https://cs.chromium.org/chromium/src/chrome/browser/extensions/api/input_ime/input_ime_api.cc?dr=CSs&g=0&l=239
Labels: M-69
Status: Started (was: Assigned)
Sure.

hmmm, I could reproduce this issue on Evernote, Slack and Gmail, but didn't happen on Play Store search box and Google Map's search box.
As the method mentioned by Darren returns always the same value, I don't think it's caused by the method.
Cc: yusukes@chromium.org
It does't happen on Google Docs and both of Slack and Google Docs has TEXT_INPUT_TYPE_TEXT, so it does't depend on TextInputType.

Cc: wuyingbing@chromium.org
+wuyingbing@

Changing the return value of ArcImeService::GetTextInputFlags() to TEXT_INPUT_FLAG_AUTOCAPITALIZE_WORDS or TEXT_INPUT_FLAG_AUTOCAPITALIZE_CHARACTERS doesn't change the behavior....
So, is this flag used actually?
I experience the behaviour of capitalization after periods in the on-screen keyboard in tablet mode of a Pixelbook, outside of Android apps. It's very frustrating because it counts as having Shift pressed, so pressig Enter does not send the message in several chat applications (Discord most notably).
Cc: -wuyingbing@chromium.org wuyilexer@google.com lexer@google.com
Cc: -wuyilexer@google.com wuyingbing@chromium.org
Owner: shend@chromium.org
As it happens outside of Android apps, I don't think a cause of this issue is in Android apps. My guess is some combination of text input flags, text input type and text input mode causes this issue.

Darren, can you take a look at this or redirect to someone in IME team? I won't have time to fix this in this week :/
Yeah no worries, I can investigate (although c#13 seems to be a separate issue of capitalization after periods).
Cc: shuchen@chromium.org
Played around a bit...seems like we are passing the correct autoCapitalize flag ("sentences") to IME when focusing. In fact, the input context looks identical for web focus vs android focus. So I'm not sure why the decoder would have different behaviour for web vs android, given the same input context.

The play store search bar is fine because the text type is "search", so it seems like the decoder ignores autoCap for special text types.

Adding shuchen@ for ideas since he recently plumbed the autoCapitalize flag.
I digged a bit deeper. Doesn't seem to be related to autoCapitalization flag. The shift key toggling is coming from the decoder directly, not from shift prediction. Basically, what's happening is:

1. We press "h" and then press space
2. We call setContext in the decoder with " " (<- incorrect step)
3. Decoder thinks it's a new sentence, and turns on the shift key

The correct behaviour should be:

1. We press "h" and then press space
2. We call setContext with "h "
3. Decoder sees that it's not a new sentence, and doesn't turn on the shift key

Now the question is...who is responsible for getting the context? Is the ARC IME implementation supposed to provide the context?
Looks like TextInputClients are supposed to provide the context (through the "setSurroundingtext" API). For web and native text fields, the context is the entire text content of the input field. For ARC++, the context is always a single character.

We should make ARC++ return the correct context.
Cc: shend@chromium.org
Owner: yhanada@chromium.org
Thanks shend@ for the investigation.

Over to yhanada@ for the fix on ARC side.

Thanks for the investigation. I'm working on ARC side fix...
Status: Fixed (was: Started)
This should be fixed in 10933.0.0 and after it.
I'm requesting merge to M-69 on internal bug tracker.

Hello there,

I just bought a new chromebook and it updated and this is an issue in the discord app.
What version are you on?

Comment 26 Deleted

Version 68.0.3440.118 (Official Build) (64-bit) @shend
Thanks! I believe the fix is only in version 69 and onwards. From https://chromiumdash.appspot.com/schedule, it looks like 69 will start rolling out to stable from Sep 11.
I'm not happy bc it's not fixed yet
re: #29, please confirm which version you're on by entering chrome://version into the URL field.
Components: Infra>Client>ARC
Components: -Infra>Client>ARC Platform>Apps>ARC
It's fixed for me. The new smaller one handed keyboard option is buggy
though. Great idea, hope the execution can be honed.
My chromebook says its up-to-date and this issue is still not fixed. Help please.
You have to wait for Stable to hit version 69 or change your channel to Beta.
I was told that was going to be Sept. 11th? Is there a new date?
Hmm, AFAIK M69 hasn't hit stable yet. I'm not sure when that will be. Sorry!
M69 Stable rollout begins in the week of 9/17.

The onscreen keyboard is still f*cked up. Now it won't capitalize the first
word of a new sentence and if you hit the CAPS key do do so, it doesn't
return to lower case for the next word on the recently introduced condensed
keyboard. On the full screen keyboard it doesn't capatalize the first word
of a sentence but it returns to lower case on the second word on it's own.
Experienced this on my Asus c100 and Samsung Chromebook Plus V1.
 I don't mean to complain but this is such basic stuff...Bluetooth hasn't
worked in a while either...and Google is to touting Chromebooks as a viable
alternative to iPads or Surface's?!?!?!? They not quite there yet except
maybe on the Pixelbook or Slate which, from what I understand has more
finished software than other Chromebooks. Why not roll the same better
finished software to everyone else...it just makes so much sense. Google
Plus (from the Play Store) has limited functionality too...If some of this
basic stuff doesn't get flushed out soon, I'll probably get a Microsoft
Surface Go. Thanks for letting me rant.
Best,
Rob Watkins

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Hi, these have been corrected, and you should see the fixes in newer builds on all devices.
- proper capitalization (issue 893712)
- caps lock bug (issue 886558)
Thank you. What about Blutooth, and basic rendering in G+ and Facebook? I
can't reply to a comment in either app because the window that comes up
with choices to comment things like: one plus, see who commented, etc. is
usually just a thin slit, with no options to click on. If you turn the
Chromebook to landscape orientation, it sometimes partially corrects it but
not always...Google + is particularly bad when it comes to this stuff. I
know Google Plus is going away at the end of next summer but myself and a
fairly dedicated bunch of users use it more than any other social platform.
I co-own a large Motorola communityin Google Plus, and moderate in a few
Google Pixel based communities. Having full Google Plus (Play Store version
as the web version sucks but is fully functional) functionality on a
Chromebook would be awesome. Thanks again for your quick response. I hope
this stuff can be sorted out in the not too distant future. Otherwise, I
really like Chrome OS in general and prefer it to iOS on an iPad or Windows
10...
Rob
For the G+ & Facebook rendering, can you submit a new bug at crbug.com/new and cc me?  Please include some screenshots or file a feedback with your username (incl screenshot) so we can see exactly what's going on.

For Bluetooth, same thing - if we can get specific about the exact problems you're finding, we have a chance to understand what's happening.  Feedback reports are especially helpful for Bluetooth, since problems there can't identified from the screen, we need to use the debugging logs.  You can file a feedback report immediately when you see an issue and that gives the best data.
Not long after the last email you sent me,  I downloaded Chrome OS 71 and
for the first time since owning  a Chromebook, when using Google Plus and
clicking on the hamburger menu, all options rendered!!!! Yay!!! I know it's
a dying platform, but it's my social media place of choice. Also, the
onscreen keyboard is doing CAPS correctly for the first time in a while.
The floating keyboard is a bit wonky when glide typing but seems to be
improving over time. Bluetooth is still broken, you asked for reports etc.
It's already well documented by other people having the same issue. In
fact, in 71, the option to use Smart Lock (via a Bluetooth connection) was
removed entirely on the log in page... Facebook is less prone to force
closing, but still does about 40% to 50% of the time versus 80% to 90%
before Build 71...Instagram won't render to full page with any regularity
and when it does it's in portrait mode only and crashes often in that mode.
Otherwise good stuff! This is a snapshot of my day to day observations with
the OS. I hope it's not too broad. Thank you ALL for the great work you do
on this platform. I enjoy using it.
Rob

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Sign in to add a comment