I'm able to repro this on a ToT Linux build at r409519.

It looks like Blink isn't updating the PRIMARY selection anymore. If I highlight text in urxvt, middle-clicking in a textarea pastes it, but if I highlight text on a webpage, the previous selection (rather than the current one) is pasted when middle-clicking either in urxvt or Chrome.

Ctrl-C in Blink seems to successfully update CLIPBOARD, though.

The problem looks like it's specific to Blink; when I highlight text in the omnibox I can paste it in urxvt with middle-click.

I don't know anything about Blink's clipboard implementation, although I assume that it ends up going through the code in ui/base/clipboard.

https://codereview.chromium.org/2130133004 looks like it recently moved around some selection code in RenderWidgetHostViewAura. Checking what happens when I revert locally...

Yep, works again when I revert https://codereview.chromium.org/2130133004.

The error seems to be that TextInputManager::GetActiveWidget() only deals with TextSelection in <input> and text area. I have an ongoing CL which fixes this issue on Aura: https://codereview.chromium.org/2208093004/.

I'm going a bit crazy here. "What do you mean I have to press ctrl + c?" :)

 Issue 633997  has been merged into this issue.

 Issue 633773  has been merged into this issue.

This is super annoying. I'm bumping this up to ReleaseBlock-Beta. I don't think we should be shipping to Beta without select-updates-primary-selection feature.

I have CQ-ed the fix and hopefully it'll land today. Do we need to merge this fix for the beta branch?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0b1041f656728be7aba9923c9ac21fd4448b0c15

commit 0b1041f656728be7aba9923c9ac21fd4448b0c15
Author: ekaramad <ekaramad@chromium.org>
Date: Tue Aug 09 14:36:49 2016

Use focused RenderWidgetHostImpl instead of TextInputManager::GetActiveWidget() to obtain TextSelection information.

TextInputManager::GetActiveWidget() should be exclusively used in
scenarios where <input> is focused as it returns the
RenderWidgetHostImpl corresponding to a RenderWidget which has a focused
<input>.

BUG= 634148 

Review-Url: https://codereview.chromium.org/2208093004
Cr-Commit-Position: refs/heads/master@{#410665}

[modify] https://crrev.com/0b1041f656728be7aba9923c9ac21fd4448b0c15/content/browser/renderer_host/render_widget_host_view_aura.cc
[modify] https://crrev.com/0b1041f656728be7aba9923c9ac21fd4448b0c15/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc

I don't think the bug is in beta (Chrome 53), is it?  Only in 54, the dev channel, so the ReleaseBlock-Beta is just to say that you can't branch 54 to make the new beta, without the fix in.

The patch that caused the regression was at 406936 which is way after M53 beta I suppose. I guess I can mark this as fixed and someone kindly verify.

I encountered this bug last week, in google-chrome-beta on Goobuntu:
Version 54.0.2816.0 beta (64-bit)

Is that different from the public beta channel?

works for me, thanks!

Chromium	54.0.2825.0 (Developer Build) (64-bit)
Revision	1ebe1f94e110f1585748825989d995bbcb233d91-refs/heads/master@{#410671}
OS	Linux 
JavaScript	V8 5.4.382
Flash	
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2825.0 Safari/537.36

(#14 was answered over email: The beta channel is indeed on M53. There was a brief issue that resulted in M54 going out internally.)

 Issue 636485  has been merged into this issue.

Tested the issue on Linux Ubuntu 14.04 using 54.0.2830.0.Observed that 'New Paste' is pasted by selecting and middle-clicking to paste.
Please find attached screencast.

Marking it as TE-verified.

Deleted: 634148.ogv 1.0 MB

	634148.ogv 1.0 MB View Download

 Issue 639343  has been merged into this issue.

 Issue 644746  has been merged into this issue.

 Issue 645350  has been merged into this issue.

Issue 635992 has been merged into this issue.