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

Issue 725703 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Regression

Blocking:
issue 316275



Sign in to add a comment

hterm: unable to paste copied text with right-click on CrOS

Project Member Reported by sdantul...@chromium.org, May 23 2017

Issue description

Google Chrome	60.0.3105.0 (Official Build) dev (32-bit)
Revision	0
Platform	9578.0.0 (Official Build) dev-channel elm

What steps will reproduce the problem?
1. Copy text from any browser page
2. Open crosh terminal using Ctrl + Alt + t
3. Right-click to paste the copied text

What is the expected result?
Text is pasted.

What happens instead?
Nothing happens.
 

Comment 1 Deleted

Comment 2 by vapier@chromium.org, May 23 2017

Blocking: 316275
we changed behavior recently to address  issue 316275 .  the intention of the code was to use middle mouse button on non-X11 platforms (including CrOS), but there was a bug that caused CrOS to use button 3 (right click) all the time.  once we fixed that, this issue came up.

the detection is based on agent.  but looks like we really want to detect based on whether the mouse has a middle button.  not sure if that's possible ... i'll have to do some searching on the topic.

or maybe we want to split things so that mouse-right-click-pastes is a dedicated bool, and we keep mouse-paste-button, but change auto behavior to always be button 2 (for middle button).
With touchpad: With two finger click, text is not pasted.
With mouse: When I click on the middle button, text is pasted

Comment 4 by vapier@chromium.org, May 25 2017

Owner: vapier@chromium.org
Status: Started (was: Untriaged)
Project Member

Comment 5 by bugdroid1@chromium.org, May 30 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/680b27bb0ed7a6bfbe1e85eb8210c48c5c86085a

commit 680b27bb0ed7a6bfbe1e85eb8210c48c5c86085a
Author: Mike Frysinger <vapier@chromium.org>
Date: Tue May 30 20:22:34 2017

nassh: options: wire up sendstring for paste events

This let's people test out paste commands like CTRL+V and mouse buttons
in the preview window.

BUG= chromium:725703 

Change-Id: Ifd7a63e912d077be58b5b83188eca5fe85a92b8e
Reviewed-on: https://chromium-review.googlesource.com/513822
Reviewed-by: Brandon Gilmore <varz@google.com>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/680b27bb0ed7a6bfbe1e85eb8210c48c5c86085a/nassh/js/nassh_preferences_editor.js

Project Member

Comment 6 by bugdroid1@chromium.org, May 30 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/847577f3e8a6938064e6b905548e0d2f49b6052f

commit 847577f3e8a6938064e6b905548e0d2f49b6052f
Author: Mike Frysinger <vapier@chromium.org>
Date: Tue May 30 20:23:38 2017

hterm: add a sep option for pasting on right clicks

We currently only support pasting for one mouse button.  For most
systems, this isn't a big deal as users as used to only one button
pasting text (either because a middle button isn't common, or it
isn't commonly used).  But on X11/Linux and CrOS systems, we have
an intersection of users and mice where right & middle pasting is
expected -- Chromebooks only have two buttons, and you can only
right click w/the touchpad.   But we have devs coming from Linux
that use middle paste a lot, and they can hook up three button
mice to the system.

So let's add a dedicated option for pasting on right clicks, and
default it to on for all platforms.  This leaves the other paste
button to auto select the middle button, or for users to pick any
other button manually.

BUG= chromium:725703 

Change-Id: I0150ede70d1371b8d7ab85837664b74a9f1317fb
Reviewed-on: https://chromium-review.googlesource.com/513446
Reviewed-by: Brandon Gilmore <varz@google.com>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/847577f3e8a6938064e6b905548e0d2f49b6052f/hterm/js/hterm_preference_manager.js
[modify] https://crrev.com/847577f3e8a6938064e6b905548e0d2f49b6052f/hterm/js/hterm_terminal.js

Project Member

Comment 7 by bugdroid1@chromium.org, May 30 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/libapps/+/2edd36139eb27918c8f98e7430adca8126026630

commit 2edd36139eb27918c8f98e7430adca8126026630
Author: Mike Frysinger <vapier@chromium.org>
Date: Tue May 30 20:23:54 2017

hterm: switch to standard MouseEvent.button

The MouseEvent.which field has not been standardized, so switch to the
standard MouseEvent.button field.

Unfortunately the values don't map exactly -- they're off by 1.  For
.which, {1,2,3} => {left,middle,right}, but .button maps {0,1,2} =>
{left,middle,right}.  People who haven't changed the default (auto)
won't notice.  But people who have made a selection need to update
the option.  If they used this a lot, they should notice quickly.

BUG= chromium:725703 

Change-Id: I0b7290f96cc6dd4024a403eafaa9baf5373c0a77
Reviewed-on: https://chromium-review.googlesource.com/513564
Reviewed-by: Brandon Gilmore <varz@google.com>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/2edd36139eb27918c8f98e7430adca8126026630/hterm/js/hterm_preference_manager.js
[modify] https://crrev.com/2edd36139eb27918c8f98e7430adca8126026630/hterm/js/hterm_terminal.js
[modify] https://crrev.com/2edd36139eb27918c8f98e7430adca8126026630/hterm/js/hterm_vt.js

Comment 8 Deleted

Comment 9 by vapier@chromium.org, May 30 2017

Labels: Merge-Request-60
looks like just missed the M60 branch point.  cherry picking back the one CL should be safe:
  https://chromium-review.googlesource.com/513446
Project Member

Comment 10 by sheriffbot@chromium.org, May 31 2017

Labels: -Merge-Request-60 Hotlist-Merge-Approved Merge-Approved-60
Your change meets the bar and is auto-approved for M60. Please go ahead and merge the CL to branch 3112 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 11 by bugdroid1@chromium.org, May 31 2017

Labels: merge-merged-release-R60-9592.B
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/manifest/+/78f420a4a1ed827500351d664a0224109528ef2c

commit 78f420a4a1ed827500351d664a0224109528ef2c
Author: Mike Frysinger <vapier@chromium.org>
Date: Wed May 31 21:22:34 2017

update libapps to pull in right-click fix

This rolls in two fixes for the default crosh bundle.
  hterm: add a sep option for pasting on right clicks
  nassh: options: wire up sendstring for paste events

BUG= chromium:725703 
TEST=None

Change-Id: I01e50316360b7c942c989b8226aed17cb65c73f2
Reviewed-on: https://chromium-review.googlesource.com/520103
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/78f420a4a1ed827500351d664a0224109528ef2c/full.xml

Project Member

Comment 12 by bugdroid1@chromium.org, May 31 2017

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/manifest-internal/+/8f6a15015c60504b9a7f904a71b6057f6a9ec794

commit 8f6a15015c60504b9a7f904a71b6057f6a9ec794
Author: Mike Frysinger <vapier@chromium.org>
Date: Wed May 31 21:22:34 2017

Labels: -Merge-Approved-60 Merge-Merged
Status: Fixed (was: Started)
Status: Verified (was: Fixed)
As verified in M60.0.3112.20:9592.11.0 dev peppy, the paste copied text in hterm via touch pad is working now.

Sign in to add a comment