New issue
Advanced search Search tips

Issue 900152 link

Starred by 1 user
Status: WontFix
Owner:
orinj@chromium.org
Closed: Oct 30
Cc:
nyerramilli@chromium.org
rbasuvula@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Unwanted space selection is observed while dragging link into omnibox.

Reported by db...@etouch.net, Oct 30 
Chrome Version: 72.0.3595.2 Revision 4af8b5a14fa87ad1e81fa9ae20c30f9a8c1494cb-refs/branch-heads/3595@{#4}(32/64 bit)
OS: Windows (7,8,8.1,10),Mac(10.13.1,10.13.6,10.14.1) and Linux(14.04 LTS).  

What steps will reproduce the problem?
(1) Launch chrome, open NTP and hitt space bar when cursor is in omnibox.
(2) Now drag any link or thumbnail to omnibox and observe.

Actual: Unwanted space selection is observed while dragging link into omnibox.

Expected: No such a space selection should seen.

This is a regression issue, broken in 'M69', will soon update bisect info:

Good Build:69.0.3456.0(Revision:566382)
Bad Build: 69.0.3457.0(Revision:566678)
Actual_Video.mp4
340 KB View Download
Expected_Video.mp4
262 KB View Download

Comment 1 by db...@etouch.net, Oct 30

Labels: hasbisect
Owner: orinj@chromium.org
Status: Assigned (was: Unconfirmed)
You are probably looking for a change made after 566658 (known good), but no later than 566665 (first known bad).
CHANGELOG URL:

https://chromium.googlesource.com/chromium/src/+log/f8595f77b3a7ce4753daf774a4f5c0db92c5b15b..986c1770a5b4c75026bedbf9bd12143bce421a29

Suspect: https://chromium.googlesource.com/chromium/src/+/f36f8d7305d60083414ad484165c5e10b80bed1b

@orinj: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Note: 
1 Tried per revision bisect on Windows ,Mac and Linux OS but unable to perform the same since getting "RuntimeError: We don't have enough builds to bisect" error
2 Issue is also seen on Beta build #71.0.3578.20 and Canary build #72.0.3596.0

Comment 2 by orinj@google.com, Oct 30

Status: WontFix (was: Assigned)
Yes, it appears that changing the code has caused an observable change in behavior.  But that is to be expected, and is not always a bad thing.  What I am seeing here is an improvement: the user can actually see the text that is being replaced by the drop.  It doesn't matter that the text is only whitespace.  The drop behavior here is much like pressing Ctrl+A to select all text, and then typing to replace it.

Marking as WontFix because this has been addressed before:

https://bugs.chromium.org/p/chromium/issues/detail?id=853678
https://bugs.chromium.org/p/chromium/issues/detail?id=854570
https://bugs.chromium.org/p/chromium/issues/detail?id=329319

The TL;DR is that marking the text to be replaced as selected is preferable to showing a drop insertion cursor, custom marking, or nothing at all.
►

Sign in to add a comment