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

Issue 857119 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Alt modifier is reported on AltGraph |keydown| under Linux/ChromeOS

Project Member Reported by w...@chromium.org, Jun 27 2018

Issue description

Chrome Version: 69.0.3464.0 (Official Build) dev (64-bit)
OS: ChromeOS

What steps will reproduce the problem?
(1) Navigate to the DOM Keyboard Event Viewer: https://w3c.github.io/uievents/tools/key-event-viewer.html
(2) Configure a keyboard layout that uses the AltRight key as the AltGraph modifier.
(3) Press and release the AltGraph key.
(4) Press AltGraph+<key> and release it.

What is the expected result?

At #3 and #4, expect that none of the events show the "Alt" modifier set.

What happens instead?

At #3 the |keydown| event for AltGraph is reported with both Alt and AltGraph modifiers set.

This was originally reported by zachary.milonas@westwing.pl in  issue 856147 , as part of a related bug report.
 

Comment 1 by w...@chromium.org, Jun 27 2018

Labels: M-69
Cc: bokan@chromium.org nzolghadr@chromium.org
Does anyone currently own keyboard events?
Part of it is input-dev. Some of it is Gary and some other folks (Like the keyboard Lock API and whatnot). What is "AltGraph" in this issue? How should I do the second step?
Re #3: AltGraph is the meaning of the AltRight key under certain keyboard layouts (most European layouts like Fr-FR or En-GB, for example), instead of it meaning Alt.
Labels: Needs-Feedback
Still not sure how to accomplish the step 2. Is there a configuration in ChromeOS I need to change to get this issue to reproduce?
Re #5: Yes, you need to use Settings->Keyboard to add a keyboard layout that uses the right-hand Alt key to mean AltGraph, e.g. Fr-FR or En-GB layouts, then make sure you've got that layout active (if you left multiple layouts available), then use the event-viewer to repro the issue.
Labels: -Needs-Feedback
Owner: nzolghadr@chromium.org
Status: Assigned (was: Untriaged)
Note that this isn't a Blink issue, but an issue in the platform keyboard input & keyboard layout handling on ChromeOS.
Cc: kpschoedel@chromium.org
kpschoedel: Can you provide a pointer to where this would need updating, for CrOS?
I'll take a look. My suspicion is that it's a hold-over of some part of the Windowsish Alt+Ctrl behaviour mentioned in the bug linked above.

On 67.0.3375.0 I only see the Alt flag on the initial AltGr press, and then I also see the *release* having key='Alt', both of which are wrong of course.
I filed issue 681362 for the broken |key| value in keyup events, FWIW, back in M57.
Cc: weidongg@chromium.org
 Issue 810103  has been merged into this issue.
#10 Ah, I missed that. I'm fairly sure the AltRight-to-Level3 map is consistently correct.

I would start by logging everything going on in KeyboardEvdev::DispatchKey(). That should classify the problem into (a) modifier management in KeyboardEvdev, (b) XKB Lookup, or (c) some mysterious change after ui::Event creation. (I don't see anything obviously wrong with any of these.)
Re #12: Good point; the Windows implementation of event-modifiers had some strange logic that would re-construct the modifiers when converting from ui::KeyEvent to WebKeyboardEvent, IIRC - perhaps that's what is happening here as well.

Sign in to add a comment