adding some random recent clipboard CL authors while I bisect this.

You are probably looking for a change made after 451715 (known good), but no later than 451716 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/2f16bd68bd7e191db66f96d2c761017902074d91..7afbab0f7619c89aa7a5896024d1628a59cc0ef1

https://codereview.chromium.org/2685723005 -> mwrobel@opera.com or yosin, can you take a look at this regression? Should I just revert?

The CL mentioned in #c3 makes Blink the spec conformance[1]. Thus, we don't want to
revert this.

Could you change hterm implementation to follow the spec?


[1] https://w3c.github.io/clipboard-apis/#to-fire-a-clipboard-event

Please don't wontfix a bug as it will never get actioned if you do that.

vapier - what do you think here? Can hterm be fixed?

When this hits later channel, a lot of people are going to get frustrated, so marking RB-Beta.

 Issue 697179  has been merged into this issue.

Issue 697136 has been merged into this issue.

We can fix hterm but do we have any research into other apps that depended on the previous noncompliant behavior? I don't see an intent thread on blink-dev related to this change.

that Chromium commit & referenced bug is pretty light on details as to what it actually changed.  frankly, the commit message there is just terrible.

playing around with new versions & old versions, it looks like the issue is that our registered 'copy' event is now fired when we call document.execCommand('copy') where it wasn't previously.  this leads to an infinite loop where our event handler indirectly calls document.execCommand('copy') which triggers the event handler which ...

if you guys go into the SecureShell options page and set use-default-window-copy to true, does that fix things ?

re: #12 - setting "use-default-window-copy" to true makes copy work again in Secure Shell 0.8.34.4 on Chrome Canary 58.0.3028.0

I can repro in guest mode *without* the secure shell extension.

When we invoke a standard ctrl + alt + t shell, the same no copy/paste behavior occurs.

crosh/SecureShell both use hterm, so it's expected they'd behave the same

the workaround is the same too since they also share the options page

Please add the OSs that this is applicable to.  Thanks!

 Issue 698932  has been merged into this issue.

Just to update, M-58 probably will be promoted to Beta next week, since this is marked as Beta blocker please plan the fix accordingly.

I had a similar issue. I found a work around in the settings of my chromebook.

1) Open a crosh shell
2) CTRL + Shift + P
3) Scroll down to the "Copy & Paste" section
4) Make sure all items are checked
5) Scroll down to "Keyboard"
6) Check the boxes for "ctrl-c-copy" and "ctrl-v-paste"

This fixed my issue and enabled me to use the CTRL+C and CTRL+V in my shell sessions.

What is our next step here? It sounds like we need a new spin of Hterm or a change to the default settings for it?

We need this soon if we are to promote 58 and we continue to consider this a blocker.

i wasn't planning on making a change to hterm/Secure Shell since the Chromium change has been reverted in  issue 700163 .  i don't know if they were going to cherry pick that back to M58 though ... i'll follow up to that bug.

for M58 right now, there is an easy workaround, but you have to know to do it first ...

A friendly reminder that M58 beta Promotion is scheduled on 03/16 and RC cut on 03/15( Wednesday). Please make sure to land the fix and get it merged into the release branch ASAP.

Also tracked in  crbug.com/700163 , the revert was cherry picked into M58 here: https://codereview.chromium.org/2745353002/

All we need now is just to verify that this behavior is fixed on M58 beta.

I've verified that copying text in Secure Shell works on Linux 59.0.3041.0 and Mac 59.0.3042.0, so we can mark this as fixed.

My merge CL was landed (Tue Mar 14 03:44:52 2017) slightly after the last Dev channel release (Tue Mar 14 00:02:12 2017).  It should appear on Dev channel the next time they update it.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-58; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-58 label, otherwise remove Merge-TBD label. Thanks.

Confirmed that the reverted CL is in M58 Branch.

https://chromium.googlesource.com/chromium/src.git/+/ea1abaf0d7e6c26dc323607901c91b27a72e4979

Verified Chrome OS version 58.0.3029.31/934.18.0 kevin

 Issue 702254  has been merged into this issue.