Unwanted input in new tab's address bar with non-Latin KB layout activated
Reported by
andrei.d...@googlemail.com,
Dec 12 2016
|
||||||
Issue description
Chrome Version : 56.0.2924.21
OS Version: openSUSE Tumbleweed 20161210 x86_64
URLs (if applicable) : N/A
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5: N/A
Firefox 4.x: N/A
IE 7/8/9: N/A
Prerequisites: some non-latin keyboard layout in the inputs list
What steps will reproduce the problem?
1. Navigate to some page (say, http://example.com)
2. Switch to a non-latin keyboard layout
3. Press Ctrl-T to open new tab
What is the expected result?
The tab is opened with empty address bar
What happens instead of that?
The tab is opened and the address bar is prefilled with a symbol active layout has on a "T" key ('е' for Russian ('xkb', 'ru'), 'ف' for Arabic ('xkb', 'ara'), 'ш' for Bulgarian ('xkb', bg'), 'ტ' for Georgian (xkb-ge) etc)
Please provide any additional information below. Attach a screenshot if
possible.
UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.21 Safari/537.36
Environment: GNOME 3.22
Input sources list:
> $ gsettings get org.gnome.desktop.input-sources sources
> [('xkb', 'us'), ('xkb', 'ru'), ('xkb', 'ara'), ('xkb', 'bg')]
Note 'ara' and 'bg' were added for reporting purposes
Also I was unable to reproduce it for xkb-zh or xkb-ja
xkb options in effect:
> $ gsettings get org.gnome.desktop.input-sources xkb-options
> ['grp:shift_caps_toggle', 'misc:typo', 'lv3:ralt_switch', 'grp_led:scroll', 'keypad:oss']
A video illustrating the issue: https://youtu.be/yqPVRexlwhI
,
Dec 12 2016
,
Dec 13 2016
Tested in reported chrome #56.0.2924.21 and Dev #57.0.2946.0 on Ubuntu 14.04 able to reproduce the issue. Below are the Bisect Details: Bisect Info: ============= Good Build: 56.0.2916.0(Revision - 431463) Bad Build: 56.0.2917.0 (Revision - 431726) Bisect URL: =========== You are probably looking for a change made after 431673 (known good), but no later than 431674 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/e125f89dbe38c925a96cbc905dcd18b7f31deb20..d093f7b054b78f6740e4aa96e163ae0383ee3cca From the CL above, assigning the issue to the concern owner @ chongz : ------------------ Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner. Review-Url: https://codereview.chromium.org/2474083002 Note: Not able to reproduce the issue on Mac 10.11.6 & Win 10.0.
,
Dec 13 2016
Thanks for the report! This should be my issue, I will dig into it.
,
Feb 13 2017
,
Feb 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4127317ca378c1cd8be4dd09428f0dd232888f68 commit 4127317ca378c1cd8be4dd09428f0dd232888f68 Author: chongz <chongz@chromium.org> Date: Tue Feb 14 17:06:24 2017 [Linux] Ctrl should be considered as system modifier and not producing characters |KeyEvent::GetCharacter()| returns the character value of the DomKey, which is not necessarily the character to be produced by the event. e.g. "Ctrl+t" doesn't produce a printable character, but the DomKey is "t". |Textfield| (and other components) relies on the system modifier check to detect whether they should put a character, and this CL adds Ctrl key as an additional filter. This is based on the fact that XKB doesn't have a combination with Ctrl that maps to a printable character. For Windows: 1. We can't do it because Ctrl+Shift+2 should insert ZWNJ with Persian Keyboard 2. It's currently not breaking because Windows native 'keypress' has different |key| value < 0x20 For Mac: 1. Mac doesn't have this issue and it seems to be using a different approach in |RenderWidgetHostViewMac::insertText| Related issue https://crbug.com/633838 BUG= 673302 Review-Url: https://codereview.chromium.org/2580483002 Cr-Commit-Position: refs/heads/master@{#450387} [modify] https://crrev.com/4127317ca378c1cd8be4dd09428f0dd232888f68/ui/views/controls/textfield/textfield.cc [modify] https://crrev.com/4127317ca378c1cd8be4dd09428f0dd232888f68/ui/views/controls/textfield/textfield_unittest.cc
,
Feb 14 2017
,
Feb 16 2017
Tested the issue on Ubuntu 14.04 using chrome latest Dev M58-58.0.3013.3 by following steps mentioned in the original comment. Observed that New tab is opened with empty address bar as expected. Hence adding TE-Verified label. Please find the screen cast for reference. Thank you!
,
Feb 19 2017
Awesome, thank you! Could it be backported to M57?
,
Mar 8 2017
Issue 687950 has been merged into this issue.
,
Mar 17 2017
,
Mar 21 2017
Issue 702029 has been merged into this issue.
,
Mar 21 2017
Issue 703561 has been merged into this issue.
,
Apr 7 2017
Issue 708952 has been merged into this issue.
,
Apr 10 2017
Issue 705281 has been merged into this issue.
,
Apr 11 2017
Issue 709972 has been merged into this issue.
,
Apr 20 2017
The issue seems to be solved in 58.0.3029.81
,
Apr 20 2017
Confirm it's fixed in chromium 58.0.3029.81-1 on Arch Linux x86_64. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by andrei.d...@googlemail.com
, Dec 12 2016