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

Issue 776386 link

Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 430595
Owner: ----
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Can't use close tab shortcut when system is set to a non US locale

Reported by sandle...@gmail.com, Oct 19 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce the problem:
1. Install Google Chrome/Chromium on Arch/Fedora/Ubuntu
2. Open a tab
3. Change keyboard locale to another language
4. Try to close tab with Ctrl-W

What is the expected behavior?
Tab should close

What went wrong?
Tab did not close

Did this work before? N/A 

Chrome version: 61.0.3163.100  Channel: stable
OS Version: Linux nullptr 4.13.7-1-ARCH #1 SMP PREEMPT Sat Oct 14 20:13:26 CEST 2017 x86_64 GNU/Linux
Flash Version: 

Ctrl-T works.
Not sure why this is happening, but it is very annoying.
 
Labels: Needs-Triage-M61
Cc: kkaluri@chromium.org
Components: UI>Input>KeyboardShortcuts
Labels: Needs-Feedback
Unable to reproduce the issue on Ubuntu 14.04 with chrome #61.0.3163.100, #62.0.3202.75, observed Ctrl-W is working as expected even after changing keyboard language to Japanese.

sandler31@ Could you please retry the scenario on clean profile with no apps/extensions and let us know your observations.

Thank You...
@kkaluri I tested my Fedora with Japanese input, and it does indeed seem to work, I even tried other languages such as Russian and Arabic. The only language that does not work for me is Hebrew.
Now that I understand that it's only Hebrew, it's pretty weird to me, how can a specific language can not work?
Project Member

Comment 4 by sheriffbot@chromium.org, Nov 1 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: susanjuniab@chromium.org
Labels: M-64
Status: Untriaged (was: Unconfirmed)
sandler31@ Thanks for the feedback.

Able to reproduce the issue on Ubuntu 14.04 using the latest Stable 62.0.3202.75 and Dev 64.0.3253.3.
Changed the Keyboard layout to Hebrew language and tried CTRL-T to open new tabs. It is working fine. By using CTRL-W not able to close the tabs.
This is a Non-Regression issue as this issue is observed from M50 chrome builds.

Hence marking this as 'Untriaged' for further updates from Dev.

Thanks.
Cc: sc00335...@techmahindra.com
 Issue 798678  has been merged into this issue.

Comment 7 by ikejima@google.com, Jan 9 2018

Hi, I'm using Japanese input and meet different wrong behavior.

1. Push Ctrl
2. Push W and release
3. Push W and release
4. Release Ctrl.
 
Expected: Close two tabs.
Actual: Close only one tabs.

Same thing happen to Ctrl+T.
When I disable IME(fcitx), it works as expected.

Chrome version: Version 63.0.3239.132 (Official Build) (64-bit)
OS Version: Linux laptop 4.12.0-2-amd64 #1 SMP Debian 4.12.13-1 (2017-09-19) x86_64 GNU/Linux

Fctix version:
$ dpkg -l fcitx fcitx-skk 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                      Version           Architecture      Description
+++-=========================-=================-=================-=======================================================
ii  fcitx                     1:4.2.9.1-6       all               Flexible Input Method Framework
ii  fcitx-skk                 0.1.2-0.2         amd64             Japanese SKK input engine for Fcitx

Comment 8 by udio...@gmail.com, Feb 11 2018

Duplicate of  issue 430595 
Cc: timbrown@chromium.org
Mergedinto: 430595
Status: Duplicate (was: Untriaged)
re #7: The Japanese/fcitx issue looks like a separate issue. Please raise a separate bug.

re #8: Thank you, this is indeed a duplicate.

Sign in to add a comment