Thanks for the report. I can't reproduce this — do you think you could upload a screen recording?

Deleted: crbug_838541_no_repro.mp4 892 KB

	crbug_838541_no_repro.mp4 892 KB View Download

Restarted Chrome and it now works fine.

Closing as obsolete; thanks for the update!

I actually was able to duplicate it. It only seems to do it on non-secure websites.

Deleted: chrome-address-copy.m4v 320 KB

chrome-address-copy.m4v 320 KB Download

I'm having the same problem, the screencast uploaded by erik.uun...@jonahsystems.com (comment 7) describes the issue perfectly. But — for me, it's on both secure and non-secure sites.

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36

To clarify — it happens if the copied URL selection starts at the *beginning* of the full URL.

Attached explanations:

Deleted: this-triggers-bug.png 43.1 KB

	this-triggers-bug.png 43.1 KB View Download

Deleted: works-fine.png 46.5 KB

	works-fine.png 46.5 KB View Download

More Chrome forum reports and Twitter reports:

https://productforums.google.com/forum/#!topic/chrome/yPm5fqtKE5U

In Canary (68.0.3423.0), if I try to copy only *part* of a URL — like, say, trimming off the URL parameters, or copying only the domain name rather than the full address — Chrome refuses to copy only the portion I've highlighted. Pasting produces the *entire* URL, not just what I copied.

https://twitter.com/jbenton/status/996092611092975616

https://twitter.com/jbenton/status/996093318223319045

Others are seeing the same thing:

https://twitter.com/paperboyphil/status/996093933515149312

I copy/paste dozens of URLs every day, and it's really annoying to have to clean up URL junk after the fact instead of Chrome respecting what I copied.

Is this a bug? Or does Google just want URL parameters to travel farther than they do? Thanks!

Thanks for the reports.

Testing team, can you please figure out when this broke?

I'm going to mark this as a release blocker for Chrome 67.  (Even though we have reports from Chrome 66.)

Adding the conops hotlist as well. Thanks!

Unable to reproduce this issue on reported version, on latest stable 66.0.3359.170 , on latest beta 67.0.3396.40 and latest canary 68.0.3430.0 using Macbook Air 10.12.6, Macbook Air 10.13.3 , Macbook Pro Retina 10.13.3 , Macbook Pro Retina 10.13.1 with steps mentioned in comment#0, #7, #11. Checked for both non-secure and secure sites. Attaching screencast for reference.

@Reporter: Please check the video and let us know if we miss anything. Any further information on reproducing the issue would help in further triaging.

Thanks!

Deleted: 838541_M66,67,68.mp4 4.5 MB

	838541_M66,67,68.mp4 4.5 MB View Download

I'm not the original reporter, but —

for me the exact process on the screencast results in the bug. Not 100% of the time, but very very often.

Here is another video showing the issue. I've included the chrome://version info if that will help troubleshoot.

Deleted: chrome-bug.mp4 761 KB

	chrome-bug.mp4 761 KB View Download

I'm the Twitter reporter in #11 — I'm not sure that this is useful or not, but it happens on my machine (iMac Retina 5K, 27-inch, Late 2015) consistently in regular Chrome tabs but not in incognito window tabs. Given that it happens with clean installs as in #17, I don't believe that's the problem, but something about being in incognito fixes it for me.

@18, if there are no problems in Incognito mode, try disabling all your extensions from normal windows and try again.  It could be some extension in normal windows causing the problem.

@19, I thought the same thing so I disabled all of my extensions (that is the latest video) but the problem still existed.

CC tommycli@ -- you're likely familiar with this code.  (I know you touched the Views code for this before, so perhaps the Cocoa code cannot be that different...?  Famous last words.)  Can you perhaps take a look?

Happy to take a look. Does this look like a P1?

Would it have anything to do with Macviews Secondary UI being on or off or any other flags or experiments?

And would it have anything to do with not being able to copy text from alert dialogs on Mac Chrome?

Chromium-discuss post: "I confirmed [copying text from dialogs] worked previous to 66.0.3359.139"

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/3ZSFRxjnWLc

Chrome forum post:

https://productforums.google.com/forum/#!topic/chrome/5wO342FMXpg

This is caused by ZeroSuggest. It doesn't have anything to do with MacViews or Material Refresh.

Thanks for the details. I'll look into providing a fix this afternoon.

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

commit 64c9a03e10835c6ba7013b7a52df14867029fecf
Author: Tommy C. Li <tommycli@chromium.org>
Date: Wed May 16 17:03:41 2018

Omnibox: Fix Copy URL Adjustment interaction with ZeroSuggest.

The Copy URL adjustment code interacts poorly with ZeroSuggest, because
it is subtly wrong.

To be specific: If the popup is open, it would use the current match's
URL even if the input text is not an exact match.

This mostly affected MacOS.

This CL fixes the bug and adds a test.

Bug:  838541 
Change-Id: Ia6e5d58aa473033c8f17783ce7fbcbce3b687938
Reviewed-on: https://chromium-review.googlesource.com/1059857
Commit-Queue: Tommy Li <tommycli@chromium.org>
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559149}
[modify] https://crrev.com/64c9a03e10835c6ba7013b7a52df14867029fecf/components/omnibox/browser/omnibox_edit_model.cc
[modify] https://crrev.com/64c9a03e10835c6ba7013b7a52df14867029fecf/components/omnibox/browser/omnibox_edit_model_unittest.cc

Alright that should have fixed it, and should appear in Canary in a few days.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-67; 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-67 label, otherwise remove Merge-TBD label. Thanks.

This bug requires manual review: We are only 12 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

Cl listed at #27 is just landed in trunk, pls update the bug with canary result tomorrow.

Also since this is regressed in M66, how critical and safe this fix is to merge to M67? Pls note we only have one beta left before stable promotion.

govind: I don't think it's that critical. I think it could easily wait until M68.

Thank you tommycli@. Rejecting merge to M67 & moving to M68 based on comment #33. 

I think the merge decision should use Conops's input.  They were the ones who raised this issue, so likely know the extent of the complaints.  (E.g., will it be on the top user complaints section in the next conops report?)

Thank you mpearson@. Changing back "Merge-Review-67" just in case if we need to take this merge in basked on conops's input.

melodychu@ (ConOps POC), could you pls check whether you see a spike in user feedback for this  on M66?

 tommycli@, pls update the bug with canary result tomorrow and let us know whether it will be a safe change to merge to M67 or not if merge is needed (depends on Conops's input).

We checked feedback on this - M66 feedback about copy paste problems was not enough to drive a spike alert. 

It looks like we only received about 10 reports that mention copy paste issues with a URL and about 110 reports total that mention copy paste generically (it may or may not actually be this bug). 

Here's the link to user feedback filtered by 66: http://shortn/_SRMucF6jlS
And feedback from all versions from the last 90 days: http://shortn/_melEYlHBhP

Thanks Melody.

tommycli@ - this complaint rate sounds low enough that I'm comfortable with your original judgement about not merging to 67.

Great Mark, thanks for the extra diligence.

Thank you tommycli@,  melodychu@ and  mpearson@.

The NextAction date has arrived: 2018-05-17

 Issue 844878  has been merged into this issue.

Sounds like this might be fixed, but just in case, I wanted to include my observations from the recently merged issue:

More notes:

- Reproduces in Incognito mode

- Only the full protocol + the first character following the second second slash need to be copied.

- Performing a copy command a second time (without changing focus away from the tab) will result in the exact selected text being copied.

- Changing tabs resets the behavior.

- The url need not be the url of the current page. Focussing the omnibox and entering any text string starting with http:// or https:// then copying will produce this bug.

- I have only tested the protocols http, https, udp, ftp, and tcp. In my testing, only http and https cause the issue.

 Issue 846857  has been merged into this issue.

 Issue 848764  has been merged into this issue.

 Issue 850820  has been merged into this issue.

 Issue 856305  has been merged into this issue.

 Issue 856905  has been merged into this issue.

 Issue 863745  has been merged into this issue.

 Issue 864300  has been merged into this issue.

 Issue 864734  has been merged into this issue.

I am seeing this behavior on the current stable channel release on multiple macs running macOS 10.14 with Chrome 69.0.3497.100.  

It is possible to work-around by manually editing the URL to be just what I want to copy and then trying to select, but the old behavior where it didn't select the whole URL when I hit the Command key was superior

alan.hoyle@, please file a new bug with exact repro steps.  I'd rather your feedback not get lost on this long-closed bug.

Opened  Issue 891509 

Thanks