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

Allow webpages to consume alt+click

Reported by, Jun 11 2013

Issue description

Chrome Version:   28.0.1500.35 (WebKit 537.36)
OS Version:       4100.38.3 x86_64
Type of computer: Link

What steps will reproduce the problem?
1. Invert Ctrl + Alt
2. Create a presentation with a shape
3. Resize a shape with Ctrl (which is now mapped to Alt)

What is the expected output?
Resize ignores Ctrl mapped to Alt

What do you see instead?
Resize behaves as though Ctrl is pushed, but when the resize completes, nothing happens - behaving as though Alt was pushed

Use this sample doc:
Showing comments 10 - 109 of 109 Older

Comment 10 by, Oct 21 2013

Achuith, would this be a workable solution? Currently when a click happens when alt is down, we generate a right click. What if instead we tried sending alt-click to the web page. If the web page takes action on it (known by whether or not it called stopPropagation or preventDefault or something on the event), we don't sub in right click. If the page doesn't appear to handle it, tho, we send alt-mouse-up and then right-mouse-down, giving us the right-click menu.
Labels: Iteration-93
Status: Available
Labels: M-32

Comment 13 by, Oct 22 2013

Thanks for the clarification, ADLR. :)

Comment 14 Deleted

Comment 15 Deleted

Comment 16 by, Nov 18 2013

RyanT: This is ugly, but given the lack of movement on this bug, I'll mention it to you: You can work around this behavior in javascript.

The workaround works like this: You keep track of the alt-button state in javascript. So when Alt is pressed/release, you note it in a variable. (Also, when you lose focus, it's probably safest to assume alt is no longer pressed.)

When you get a right-mouse-button-down even that claims that alt is not pressed, while at the same time your internal alt-state tracking says that alt IS pressed, we know that this right-click is actually an alt-left-click. The javascript could then behave as if alt-left-click is being pressed.

I've done this w/ code that I use on Chrome OS, and I believe our terminal emulator (Secure Shell) does this.
Andrew, if you have sample javascript code that demonstrates this problem (not the resizing rectangle, which is quite complex), could you please add it to this bug?

Comment 18 by, Nov 19 2013

you'll notice that this prints out events that occur on the box.

Watch what happens for alt-left-click:

alt goes down
right mouse button down (claiming that alt is up)
right mouse button up (claiming that alt is up)
alt goes up

Ideally we would get this sequence of events for docs (and pages that want it):

alt goes down
left mouse button down (claiming that alt is down)
left mouse button up (claiming that alt is down)
alt goes up

Comment 19 by, Nov 19 2013

also: ctrl modifier w/ ctrl-click behaves correctly. Alt, however, has this fake-right-click behavior.

Comment 20 Deleted

The code that is responsible for the remapping is here:

It was introduced by Yusuke here:

Dan, James: Do you have any suggestions about the right way to fix this?
#21: I think that we've treated alt-click as right-click for far longer than those changes that implemented it in Ash, although I could be wrong.

The suggestion that Andrew described in #10 sounds reasonable to me if we need to keep the alt-click accelerator. Do we have metrics around how often users use alt-click vs. two-finger click?

How many web apps actually expect to receive alt-click? Note that it's typically used as a "download this link" accelerator by web browsers.
I don't have any suggestions here. While there is an "unhandled keyboard event" pass that allows the browser to handle keystrokes if the page doesn't eat them, I'm not sure if there is such a thing for mouse events.

Likewise, it's hard for me to reconcile the desire for Alt-click to be right-click vs. web pages wanting to consume Alt-click. It's very confusing when UI events are sometimes handled by the page and sometimes not (for example, Ctrl-F when focus is in the page vs. Ctrl-F when focus is in the omnibox).  If I'm used to Alt-click spawning a context menu and it works on most-but-not-all web pages, that's a very odd experience.  It seems to me like Alt-click should either always be right-click (like now) or always offered to the page.

Not that helpful, I know. :-)

I just tested alt+click on Windows in Chrome, Firefox and IE and in all cases the alt+click is send unmodified to the web page.  To me this means it's completely reasonable for a web app to rely on alt+click and so we should NOT be stealing it from the app! ("content not chrome":

If we feel it's essential that users have such a backup right-click mechanism on CrOS, then it should either use a system-defined modifier key (eg. search-click) or be an off-by-default accessibility feature.

Comment 25 by Deleted ...@, May 4 2014

I found this from a Google+ link. Just wanted to mention that this alt-click behavior is adversely affecting an app I use, Caret (Text editor). Normally alt-click activates vertical multi-line editing, Except in a Chromebook, due to this behavior. 
Someone needs to make a call here. Alex, I choose you!

I agree with #23 and #24 -- I think it'll be confusing if we keep the alt-click-means-right-click behavior but allow some pages to intercept it. I feel that we should either always treat this as right-click or never treat it as right-click.

My preference* is that we drop the right-click behavior and make alt-click behave the same way as it does on Windows, where alt-clicking a link downloads it and other alt-clicks are made available to the page.

Search-click meaning right-click makes sense to me too. This is arguably in line with the search-up/down/left/right accelerators for PgUp/PgDown/Home/End. The transition will probably be somewhat painful for users who are accustomed to alt-clicking to do right clicks.

* as one of the great unwashed masses of Linux users who are accustomed to alt-drag being grabbed by the window manager and used to move windows, and not available to apps at all
A few questions: 
 (1) Do we have a sense of how many CrOS users actually know of and use Alt+Click as right click? It seems like a pretty obscure and un-discoverable feature. I like to think I know a lot of power user shortcuts, but even I didn't know about this one ;)
 (2) What was the reasoning behind us implementing this in the first place?
 (3) Is this alt+click behaviour documented anywhere?

Others on the CrOS team might argue that we should be encouraging more users to learn that two-finger click is right click.

If I had to make a call here, I would suggest doing as derat@ suggests and removing Alt+Click as a right click alternative, but I'd like some answers to the above questions first.
See also  issue 363450 
I don't know the answers to 1) and 3), but as far as 2) goes, I'm pretty sure it was added before we controlled the whole input stack, when two-finger-clicks were quite difficult to do compared to now.
Derat, I agree with you. On mac Ctrl+Click actually gives you right click. I think making it Search+Click makes sense to me on Chrome OS.

Comment 31 by, Oct 7 2014

Has there been any progress on this one?
This affects in particular.
Making this Search+Click sounds reasonable from a keyboard shortcuts perspective. It's best for us to get off the toes of key+mouse combinations that are expected to work a certain way.

Do we have documentation about this behaviour that we can update somewhere?
I have a web app that uses alt+drag to rotate in 3D, and my Chrome OS users can't do that. I already use right-click for the context menu, and left click to pan. I can't use ctrl+click, because Macs turn that into a right click (also annoying!), and shift+click is for multi-select. So alt+click is the only option left that works on Mac and Windows. It's weird that it doesn't work on Chrome OS, forcing me to write Chrome-specific code (+1, #24). My vote is to disable this re-mapping, and let apps consume the events that actually happen.
+abodenha@ to reassign to someone on the UI team, assuming that there's still agreement to try changing "Alt+click means right-click" to "Search+click means right-click".
afakhry@ can you look into this and coordinate with kuscher@ on the right way to handle it?
Status: Started
Project Member

Comment 37 by, May 4 2015

The following revision refers to this bug:

commit 404d0118fa4c40676cbd2f6da3e5ba5d62f39b61
Author: afakhry <>
Date: Mon May 04 23:27:27 2015

Converting (Alt+LeftClick -> RightClick) to (Search+LeftClick -> RightClick)

Some web apps have behaviors for Alt+LeftClick so we had to do this

However this change will result in popping up the AppList whenever
Search+Click is pressed and then search is released while in a web
app that consumes the Search+Click by showing a context menu and
then prevents default. This context menu differs from the native
context menu in that it doesn't have its own MenuEventDispatcher.
So the Search release event is passed to the accelerator controller
and then the controller thinks the both current and previous
accelerators are the "Search" key.

We had to fix this by listening to mouse events in the AcceleratorFilter
and then clear the current accelerator in the accelerator history.

TEST=unit_tests --gtest_filter=EventRewriterTest.*

Review URL:

Cr-Commit-Position: refs/heads/master@{#328213}


Status: Fixed
The old behavior should be changed now from (Alt+LeftClick -> RightClick) to (Search+LeftClick -> RightClick). Please verify.
Labels: Hotlist-Noteworthy
This should go in release notes -- I'm not sure what the process is for flagging those sorts of issues. Is Hotlist-Noteworthy still used?
Btw, kudos to Ahmed for fixing a bug that's been outstanding for almost 2 years!
Dharani, can you please make sure this gets release noted?
Sure. I'll note this in M44 release notes.
Labels: VerifyIn-44
See  issue 489128 .

Comment 45 by, May 19 2015

 Issue 489128  has been merged into this issue.
This affected me today after the updated beta channel. The converted alt/search-bug isn't funny, because if you release the search-button, after choosing from the context menu, the search app will open.
#46: Can you provide additional details (e.g. version number) or file a separate bug about that? If I'm understanding correctly, that sounds bad, but I'm not able to reproduce it using a recent ToT 45.0.2417.0 / 7122.0 build:

1. Hold Search.
2. Click on a page in a browser window.
3. Click on Reload in the context menu.
4. Release Search.

1. Hold Search.
2. Press the touchpad down.
3. Drag to Reload in the context menu.
4. Release Search.

The Search window isn't opened in either case. Even after doing the following, I don't see the Search window:

1. Hold Search.
2. Move the cursor with the touchpad but don't click.
3. Release Search.

The only way I see the Search window is if I press and release the Search key without doing anything in between. Am I misunderstanding, or is it some other bug that's since been fixed?
#47 every time when I do a right-click using the search-button the search-app opens when the button is released. I posted to our Chromebook Deutschland community and got feedback, that it is reproducible. The only difference to your setup might be: I'm using the German keyboard setting on an Acer CB 15 (i3).

Google Chrome	44.0.2403.25 (Offizieller Build) beta (64-Bit)
Überarbeitung	df8e5b217f087c1577f91255add570485cf4bef7
Plattform	7077.21.0 (Official Build) beta-channel auron_yuna

Comment 49 by, Jun 2 2015


I can reproduce it on 44.0.2403.25 on Chromebox i3 as well, regardless of whether I select some action from the menu or not. The launcher opens every time.
I am a TC on the Chromebook Central Help Forum. We regularly teach our users to use alt-click for right-click if they are having trouble mastering the two-finger tap technique.

That is well documented on the Help page
"Right-click: Click the touchpad with two fingers, or hold Alt while doing a single click."

We have just gone through a major upheaval with the UI change that replaced the 9-box app launcher icon with the search icon for Launcher. As part of that transition, we pointed out the consistency and elegance of having the search key and search icon act the same. 

I am on 44 beta with a US English keyboard. If I press the search key and tap the touchpad (not a full "click") I get the right-click action menu. But if I then release the touchpad, I get the Search menu displayed. 

This is NOT a usable feature.
Labels: Restrict-AddIssueComment-EditIssue
I've filed  issue 495807  to track the Search-window-getting-shown issue. Please add additional details there and star it to receive updates.

I'm repurposing  issue 494977  to track updating documentation.
Issue chrome-os-partner:41043 has been merged into this issue.
Labels: -MovedFrom-30 -MovedFrom-31 -MovedFrom-32 -VerifyIn-44 M-44 ReleaseBlock-Stable
Status: Untriaged
Reopening and marking as a M44 Stable blocker to make sure some consensus is reached before pushing to a wider audience.  Discussion is ongoing.
Status: Assigned
Users have gotten used to the broken behavior and are disrupted by a change like this without warning.

xdai@ can you revert afakhry@'s change and merge the revert to 44?

Comment 55 by, Jun 4 2015

Sure, I can do that.
Project Member

Comment 56 by, Jun 5 2015

Labels: Merge-Request-44
Need to merge the revert.
Labels: -Merge-Request-44 Merge-Review-44 Hotlist-Merge-Review
[Automated comment] Reverts referenced in bugdroid comments, needs manual review.
Labels: -Merge-Review-44 Merge-Approved-44
Project Member

Comment 60 by, Jun 5 2015

Labels: -Merge-Approved-44 merge-merged-2403
The following revision refers to this bug:

commit fc814c80b15d3ec81b2ba0780b877e1e4bda427d
Author: xdai <>
Date: Fri Jun 05 16:40:53 2015

This change needs to go to branch 2403 (M44).

Revert "Converting (Alt+LeftClick -> RightClick) to (Search+LeftClick -> RightClick)" on behalf of afakhry@.

As seen in the buganizer discussion, users have gotten used to the broken behavior and are disrupted by the change without warning.

This reverts commit 404d0118fa4c40676cbd2f6da3e5ba5d62f39b61.


Review URL:

Cr-Commit-Position: refs/heads/master@{#332979}
(cherry picked from commit e54b1fc21cb1fbb5f4532009ad8181432761657c)

Review URL:

Cr-Commit-Position: refs/branch-heads/2403@{#219}
Cr-Branched-From: f54b8097a9c45ed4ad308133d49f05325d6c5070-refs/heads/master@{#330231}


Labels: -ReleaseBlock-Stable
Removing release blocker label as the change has been reverted from tot and M44.

Comment 62 by, Jun 5 2015

Reverted from ToT and M44. Assign it back to afakhry@ to decide what to do next.
Labels: Review-UI
Summary: Consider not using Alt+click to emulate right-click so pages can consume it (was: Alt-click input unavailable to web apps because Chrome OS subs in right-click)
I think that this is a UX decision at this point. (This bug probably isn't the best place for that since it's up to 63 comments now.)
Blocking: chromium:495807
Project Member

Comment 65 by, Jun 5 2015

The following revision refers to this bug:

commit fc814c80b15d3ec81b2ba0780b877e1e4bda427d
Author: xdai <>
Date: Fri Jun 05 16:40:53 2015

Labels: Hotlist-ConOps
 Issue 168285  has been merged into this issue.
Blockedon: chromium:492454
Labels: -M-44 M-45
Summary: Allow webpages to consume alt+click (was: Consider not using Alt+click to emulate right-click so pages can consume it)
Labels: -M-45 M-47
Labels: Hotlist-ShortcutRefactor
 Issue 442602  has been merged into this issue.

Comment 74 by, Dec 15 2015

​**​Please note that Review-UI label is deprecating. For all future U​X​​ or user-facing changes​ that need ​a ​review ​to launch, please have a Googler representative send an email to Chrome UI Review with information about the ​change or new feature, any design mockups, screenshots, or instructions to test ​it out.​**​
Project Member

Comment 75 by, Jul 5 2016

Labels: Hotlist-OpenBugWithCL
A change has landed for this issue, but it's been open for over 6 months. Please review and close it if applicable. If this issue should remain open, remove the "Hotlist-OpenBugWithCL" label. If no action is taken, it will be archived in 30 days.

For more details visit - Your friendly Sheriffbot
Labels: -Hotlist-OpenBugWithCL
This was reverted, so it's still an issue. I'm not sure whether we actually want to change anything here or if we've given up on this, though.

Comment 77 by, Jul 7 2016

I know it sounds gross, but one option would be to have a preference for legacy vs new behavior, and put existing users default into the legacy bucket.
An option is really the only possible solution here. We can't use the approach we used for other keys for a variety of reasons.

I'd really like to make the change but suspect we'll get a lot of pushback on creating an option for this.
We recently removed backspace to navigate-back accelerator. When users press backspace, we show an overlay suggesting the alt+left to go back instead. Can we use something similar for this too? If we detect an alt+click, we can show the overlay and suggest using search+click instead.
 Issue 650436  has been merged into this issue.
Labels: -Hotlist-Merge-Review

Comment 82 by, Apr 6 2017

ChromeOS makes this worse by only supplying three modifier keys (ctrl+alt+shift - no meta), so reserving alt always for context menu is really limiting for our app.

Comment 83 by, Jun 12 2017

Ahmed or Albert, what's the current plan here? Is this going to be pushed out again after a period with better messaging to users about the change?
Components: -UI UI>Input>KeyboardShortcuts
#79 is what we did for moving other critical keys to search, but click operations are much more complex, making that migration path problematic.  You have to deal with down and drag as well as up, so there are ordering issues in terms of when to display migration UI as well as making sure we don't accidentally trigger launcher. We tried to do the migration back in #37 and had to revert.

afakhry@, any thoughts here? Things have evolved since our last attempt and we might have better luck if we try again.
Yes, I recently fixed an issue in the AcceleratorHistory that prevented it from tracking key events with repeats properly. +weidongg@ is also working on a CL to detect if an accelerator was interrupted by a mouse click event. So yes, I expect to have better luck this time.

For migrating users we can do something like what we do for deprecated accelerators, but as you said it will be very tricky.
Blocking: 370133

Re notifying users: we currently convert 'alt + left-button press' to 'right-button press' (and subsequently, 'alt + left-button up' to 'right-button up') pretty early in the event-processing pipeline [1]. Instead of doing the conversion here, we could still detect this case, and immediately show the notification (the notification would not be about context menu, but rather about doing right-click). Not totally sure if it'd be necessary to handle other cases (e.g. drag etc.)

It would also be interesting to see how many users actually use this alt+left-click to do right-click. Maybe we could add an UMA metric in there for a release?

A couple of options for keeping alt+left-click to generate right-click, but allowing a web-page to consume the event first:

A. One option is to send the event to the web-page first, wait for it in the browser to be acked by the renderer, and convert it to a right-click only if the page did not handle the event. This is how a number of keyboard-accelerators work (e.g. shift+escape is sent to the page first, and only if the page does not handle it, does chrome show the task-manager). I think the mouse-events are acked in here [2], and so the generation of right-click can also happen here (and should not be overly complicated I think?), instead of in [1]. +dtapuska@ as input-dev owner for thoughts/suggestions etc.

B. Another option is to just avoid conversion in browser altogether, and instead do the work in blink [3]. i.e. introduce a setting for showing context-menu on alt+left-down (similar to 'show context menu on mouse-up' vs 'on mouse-down' [4]), and just show the context menu in blink if alt+left-down is not processed by JS. I think this will be the simplest (and lowest risk) to implement.

I should explicitly mention, in case it wasn't clear: with the two proposals, the alt+left-click ==> right-click will happen only for the web-page, and not for the UI. So, if you are using alt+left-click to do right-click on some part of the UI (e.g. on the tab-strip, or the shelf, wallpaper etc.), then these alternate proposals will not be sufficient. We will need some additional work on the UI side (happy to expand on this if needed).
sadrul@ Thank you for your suggestions! We definitely need data to understand how this feature is being used. From what I know, it seems that it's used to easily emulate right-click regardless of the context, so tab-strip, shelf, tray, wallpaper, etc. are included.
For the UI, we can do something similar: generate a right-down if the alt+left-down was not processed here [1] or here [2]. Or, simply trigger a context-menu for unprocessed alt+left-down events, like we do for gestures here [3].

Sadrul, your suggestion sounds good. I will try to implement it and see. Thanks!
Re #91: I found this to be a bit surprising and inconsistent. Most handlers of the left mouse button down event don't check whether Alt is pressed or not, so what we get in the post target handler is the mouse left button release, for which we show the context menu if Alt is pressed.

As a result, [See attached video] we see the action associated with the left mouse button press, and then on release, if there's a context menu controller for the event target, we see the context menu as well.

See how Alt+Clicking on the launcher icon shows the launcher, as well as the shelf's context menu.

This approach no longer emulates a real right mouse button click/release event, which might not be what we want.
1.5 MB View Download
Eh, that's ... unfortunate. I suspect there are a lot of such places in the UI? It would be nice to fix that.

In the meantime, we could workaround that! We can re-write the alt+left-down to right-down in the *pre*-dispatch phase inside views instead of in the post-dispatch phase (like [1])! So for views, the behaviour will remain pretty much the same: it will not see alt+clicks at all. But the web-page will start seeing these events, and can handle them and stop them from being turned into right-clicks.

Agreed with warx@ that he will be driving this with ovanieva@

Comment 96 by, Jun 26 2018

Owner: ----
Status: Untriaged (was: Assigned)
Status: Assigned (was: Untriaged)
Labels: Hotlist-PopularIssue
Blockedon: 890648
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!
Hi everyone,

This is still a problem for us at Figma. We've built an interface design tool that runs in the browser and the inability to use the alt key hinders the experience for all of our customers on Chrome OS. Windows and macOS allows us to leverage this modifier key for critical industry-standard interactions (e.g. drag to duplicate) that are an essential part of a designer's workflow.

We have tried to work around this by using the search key instead, but this is not a good workaround. First of all, it doesn't behave like a modifier key. Tapping it without clicking brings up the search UI and causes our app to lose focus. Also it's not something users naturally intuit, especially when they are coming to Chrome OS from other platforms where Figma is able to use the alt key as expected.

We would love to see this issue resolved.
There is a workaround that we added recently in  issue 890648 . Alt + Left Click remapping is now limited to touchpad devices only. So using an external mouse can be a way around this issue until we implement a proper solution.
afakhry@ is there an expected ETA for a long-term solution? If it's being tracked on a separate bug I would love to clean this one up in the meantime.
Wow, this issue was filed in 2013 by my then office mate ryant. If back then we had made a policy that all new devices would ship without this alt-trapping behavior, we could close this today. Should we do that now?
Because of the age of this bug I (personally) think it should be resolved, especially since there is a current work around for the issue. The only reason I can think of for this to stay open is if it would be relevant for discussions on implementing a long-term solution.
There is no work around without using an external device, unless you're speaking to something else. I don't think this should be closed. This is a product quality issue IMO, it breaks users trying to use apps on this platform.
There was already one attempt made (and then reverted) to remove the Alt+Click binding. Adding an option to control the behavior was mentioned earlier here, and I don't have any objections. For that to happen, someone on the product side should bring a proposal to UI review.
Is there a template that should be used for creating a proposal for this review? I wouldn't mind helping getting it kicked off.
We don't have a PM owner for this feature right now.
Showing comments 10 - 109 of 109 Older

Sign in to add a comment