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

Issue 113211 link

Starred by 1 user

Issue metadata

Status: WontFix
Email to this user bounced
Closed: Mar 2012
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Ctrl-Left-Shift and Ctrl-Right-Shift no longer work to set direction of <input> and <textarea> on Windows

Reported by, Feb 8 2012

Issue description

What steps will reproduce the problem?
1. On Windows, go to data:text/html,<input>
2. Click on the input
3. Type "hi!"
4. Press Ctrl-Right-Shift

What is the expected output?
The input should become right-aligned and look like "!hi".

What do you see instead?
No change.

This used to work fairly recently. (Certainly on Aug 1 2011 in Canary, see I just tried this on Chrome 16 and Chrome 18, and it no longer works.

See also,

Comment 1 by, Feb 9 2012


Thank you for your bug report.
It seems this shortcut works both on my Dev Build (18.0.1025.7 dev-m) and on Chromium r121195 (*1).


To emulate IE, we change the input direction when we RELEASE a right-shift key (or a left-shift key.) Is it possible to try the following sequence exactly and to check if this issue still happens on your PC?
1. Press a ctrl key;
2. Press a right-shift key, and;
3. Release the right-shift key.


Hironori Bono
The key pressing sequence is not the issue here.

The problem reproduces for me on my new Lenovo T420s with Windows 7 Enterprise Service Pack 1.

The problem does *not* reproduce for me on my old Lenovo T400 with Windows 7 Enterprise (with no service pack).

(I switched to the new machine about two weeks ago.)

Needless to say, Ctrl-Left-Shift and Ctrl-Right-Shift work perfectly well on *both* systems in Notepad and IE and Windows system dialogs.

I am going to try other people's Windows machines and update with the results.
Labels: -Pri-2 Pri-1 regression Mstone-18 ReleaseBlock-Stable
Status: Available
Marking as a P1 since this is a regression that affects all rtl users, feel free to change priority if you think this isn't the right.
Found four people with Windows machines, all with Win 7. No one could reproduce, although some had SP 1. No idea what's causing it to reproduce on my (new) machine. Up to you whether you want to close bug or lower priority.
If anyone can reproduce, please chime in.
Labels: -Pri-1 -regression -Mstone-18 -ReleaseBlock-Stable Pri-2 Mstone-19
Lowering priority and assigning to mstone-19, freel free to move out as necessary.
Date: Wed, Feb 15, 2012 at 8:26 AM

Greetings Aharon,

Thanks for sending your log.
In brief, it seems the keyboard driver of your new PC somehow notifies
Chrome that you pressed a left-control key (or a left-shift key) when
you actually pressed a right-control key (or a right-shift key).
Line 561 of your log shows Windows notifies your pressed a control
key. To read its details, its fExtended parameter becomes 0 even
though its ScanCode is 0x1D. (ScanCode is a hardware ID of a key.) A
standard keyboard driver of Windows maps ScanCode 0x1D to to a
right-control key, i.e. fExtended should become 1. On the other hand,
your log shows fExtended value always becomes 0. This shows your new
PC has a non-standard keyboard driver installed and it somehow
notifies Chrome that you pressed a left-control key when you pressed a
right-control key.

<00561> 005E0CB0 P WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1
ScanCode:1D fExtended:0 fAltDown:0 fRepeat:1 fUp:0
<00584> 005E0CB0 P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 ScanCode:36
fExtended:0 fAltDown:0 fRepeat:0 fUp:0
<00589> 005E0CB0 P WM_KEYUP nVirtKey:VK_SHIFT cRepeat:1 ScanCode:36
fExtended:0 fAltDown:0 fRepeat:1 fUp:1
<00662> 005E0CB0 P WM_KEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D
fExtended:0 fAltDown:0 fRepeat:1 fUp:1


Would it be possible to open a "device manager" of Windows and check
if your PC uses "Standard PS/2 keyboard"?
My Device Manager says "Standard PS/2 keyboard".

I have not installed any custom device drivers or anything of the sort.

I had made one change in settings: Control Panel / Region and Language / Keyboards and Languages / Change Keyboards / Advanced Key Settings / Between Languages / Change Key Sequence /  Switch  Input Language / Not Assigned. (I prefer to use the taskbar icon to switch keyboard languages, not a hotkey.) I now went back in there and changed it to Ctrl + Shift. I then tried to reproduce the problem, but it did not reproduce! Unfortunately, I did not check if it was still reproducing before the change, though. So, I went in there again and once again changed it to Not Assigned. The problem still did not reproduce... So, I do not know if that is what fixed it, but I can no longer reproduce.

Comment 9 by, Mar 7 2012

Status: Assigned
Available + Owner == Default Assgined

Comment 10 by, Mar 12 2012

Status: WontFix

I would like to close this issue as "WontFix" because Aharon cannot reproduce this issue any longer.


Hironori Bono
Project Member

Comment 11 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 12 by, Mar 10 2013

Labels: -Area-WebKit -WebKit-Forms -WebKit-Editing -WebKit-RTL -Feature-I18N -Mstone-19 Cr-Content-RTL Cr-Content Cr-Content-Forms Cr-Content-Editing M-19 Cr-UI-I18N
Project Member

Comment 13 by, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 14 by, Mar 20 2013

Labels: -Cr-UI-I18N Cr-UI-Internationalization
Project Member

Comment 15 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 16 by, Apr 6 2013

Labels: -Cr-Content-RTL Cr-Blink-RTL
Project Member

Comment 17 by, Apr 6 2013

Labels: -Cr-Content-Editing Cr-Blink-Editing
Project Member

Comment 18 by, Apr 6 2013

Labels: -Cr-Content-Forms Cr-Blink-Forms

Sign in to add a comment