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

Issue 759304 link

Starred by 1 user
Status: WontFix
Owner:
changwan@chromium.org
Closed: Aug 2017
Cc:
hua...@chromium.org
prashanthpola@chromium.org
█ aelias@chromium.org
changwan@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Compat



Sign in to add a comment

Chome in combination with GBoard doesn't pass through @ keypress properly to Javascript

Reported by davidaap...@gmail.com, Aug 26 2017 
Example URL:
https://gathering.tweakers.net/forum/list_message/52371169

Steps to reproduce the problem:
1. https://gathering.tweakers.net/forum/list_message/52371169 
2. Put "@" in the quickreply form at the bottom of the page (account required)

What is the expected behavior?
a popup should shown with the active users in the thread.

Screenshot: https://goo.gl/photos/98MsEWCnpDKediDy5

What went wrong?
Keypress doesn't register in chrome for some reason.

Screenshot: https://goo.gl/photos/SPsQhrC2fRyAZ7ZZ9

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? Yes ?

Does this work in other browsers? Yes

Chrome version: 60.0.3112.107  Channel: stable
OS Version: 6.0.1
Flash Version: Shockwave Flash 26.0 r0

Using the swiftkey keyboard, it does also work in Chrome.

Also tried using the latest firefox on mobile (55.0.2), it works there.

Also works correctly in the latest Chrome & firefox on desktop.

Comment 1 by phistuck@chromium.org, Aug 28 2017

Components: IO>Keyboard UI>Input>Text Blink>Input
Labels: Hotlist-Interop

Comment 2 by ppolise...@chromium.org, Aug 29 2017

Cc: prashanthpola@chromium.org hua...@chromium.org
Labels: Needs-Bisect
Hello

Thanks for reporting the issue. We were able to repro this issue on Samsung Galaxy S6 Edge/NRD90M, Chrome: 60.0.3112.107, 59.0.3071.122, 57.0.2987.132 but works fine on Chrome: 56.0.2924.87

We will provide bisect info soon.

Comment 3 by dtapu...@chromium.org, Aug 31 2017

Cc: aelias@chromium.org changwan@chromium.org
changwan@ Any ideas? I haven't debugged it yet.

Comment 4 by changwan@chromium.org, Aug 31 2017

Owner: changwan@chromium.org
Status: WontFix (was: Unconfirmed)
The Chrome behavior did not change as far as I can tell.

https://jsfiddle.net/galmacky/pz7dnnLj/

It is possible that GBoard behavior changed only for the newer version of Chrome, but I couldn't reproduce such behavior change on my test device.

If the keyboard is sending key event directly, then @ produces keypress with the correct key value. But if keyboard composes @ (therefore underlines the text), then @ produces unidentified key (or 229 keyCode value).

SwiftKey presumably sends key event directly, so avoids this issue.

Chrome's behavior of sending unidentified key / 229 for composition is explained at  issue 118639 .

The webpage should get text value directly or listen for input/composition events.
►

Sign in to add a comment