Issue metadata
Sign in to add a comment
|
Unintended drag from the page/lock icon
Reported by
jleedev@gmail.com,
Mar 9 2016
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.75 Safari/537.36 Steps to reproduce the problem: First scenario: 1. Position the mouse pointer on the page/lock icon in the omnibox 2. Press and hold the mouse button 3. Wait at least 300ms, then release the mouse button Second scenario: 1. Position the mouse pointer on the page/lock icon in the omnibox 2. Press and hold the mouse button 3. Move the mouse 4px or fewer 4. Release the mouse button What is the expected behavior? Both of the scenarios are a click, not a drag. I intended to open the origin info box, not to drag the URL. A drag should require me to move the mouse, typically 5px or whatever the platform standard is. Moving the mouse a shorter distance is a click. What went wrong? These are interpreted as a drag and drop. The web page is reloaded. Did this work before? N/A Chrome version: 49.0.2623.75 Channel: beta OS Version: OS X 10.11.3 Flash Version: In addition to superfluous drags, the lock icon is considered a drop target, which amplifies the issue from "accidental no-op drag" to "accidental navigation. Safari does not allow dragging from the URL bar to itself. ChromeOS does not consider the lock icon a drop target.
,
Mar 14 2016
We could add some hysteresis on the drag target to make this a little less easy to trigger.
,
Sep 7 2016
Combining with 588381. (This bug was lost to the winds of time because UI>Browser>Omnibox>OriginChip is dead, and this is unrelated at a technical level. We should probably remove that component or prevent it from autocompleting.)
,
Oct 19 2016
,
Nov 24 2016
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by meh...@chromium.org
, Mar 9 2016