This is a regression issue broken in M-62

Good Build: 62.0.3166.0
Bad Build: 62.0.3167.0

Deleted: Expected_settings menu.ogv 1.7 MB

	Expected_settings menu.ogv 1.7 MB View Download

Able to reproduce the issue in mac 10.12.5 using latest canary #62.0.3167.0

Using per revision bisect providing bisect results below

Bisect Information:
--------------------
You are probably looking for a change made after 489488 (known good), but no later than 489489 (first known bad).

Change Log URL: 
-----------------
https://chromium.googlesource.com/chromium/src/+log/4ab253be2b6400a6040b53023f3cdfb07d1a550e..6f4097431d1aa9b81bf51892c25f2be4a50c5904

tbarzic@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!!

Highly unlikely that adding a string would case text in settings UI become selectable (which seems to have happened here - note that the drag and drop works if you start it from the icon rather than text).

This seems to be a byproduct of making text in settings UI selectable in general: https://chromium.googlesource.com/chromium/src/+/0721d307c2e650409d287b02ddeeed4d1635b086

off to dschuyler, who reviewed the cl.

This is similar in concept to Issue 746666. Alan's call on what to do there will likely affect (apply to) what is done here.

Alan what do you think on drag and drop of menu items to the omnibox?

Although handy for the power user, I have a hard time conjuring a common use case for this type of functionality. For those that see this as a regression, I think it's just as easy to type in the direct URL to said settings page in the omnibox.  

Marking this as WontFix. Thanks! 

> Marking this as WontFix. Thanks! 

It seems that you forgot to mark it. Marking it now.

 Issue 757764  has been merged into this issue.