Issue metadata
Sign in to add a comment
|
MacViews: Dragging highlighted text from a views textfield to the Cocoa omnibox via drag and drop doesn't work
Reported by
vineetha...@etouch.net,
Apr 2 2018
|
||||||||||||||||||||||
Issue descriptionChrome Version: 67.0.3386.0 (Official Build) Revision 83a2c341a3999a32a01e268bdb891a56d6edd548-refs/heads/master@{#547395}(64 bit) OS: Mac(10.12.6, 10.13.1, 10.13.4) OS What steps will reproduce the problem? (1) Launch Chrome, navigate to www.gmail.com and sign in with valid credentials. (2) Select the text(email id) in the username field on the password bubble. (3) Now try to drag and drop the selected text in the omnibox of a new NTP and observe. Actual Result: 1. Selected and dragged text(email id) does not get dropped in the omnibox of NTP 2. After drag and drop action an unwanted black line is seen when text is entered in omnibox. Expected Result: 1. Selected and dragged text(email id) should get dropped in the omnibox of NTP 2. After drag and drop unwanted black line should not be seen when text is entered in omnibox. This is regression issue broken in ‘M-64’ and providing the bisect using per-revision bisect, Good build:64.0.3260.0(Revision: 514067) Bad build:64.0.3261.0(Revision: 514329) You are probably looking for a change made after 514119 (known good), but no later than 514120 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/4ca99c35db63893ce88910ae4456fb099e9f87ea..ebde979cc2d5fd8956cab9785ad40c276fef4811 Suspect: https://chromium.googlesource.com/chromium/src/+/ebde979cc2d5fd8956cab9785ad40c276fef4811 @vasilii: 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. Note: This issue is not observed on Windows (7,8,8.1,10) & Linux(14.04 LTS) OS Thank You!
,
Apr 3 2018
Trent, please triage accordingly. Seems like the control doesn't support Drag and Drop on Mac.
,
Apr 3 2018
These all work: - dragging from a views textfield to *Safari's* location bar - dragging from a views textfield to a <textarea> - dragging from a views textfield to a the views-browser Omnibox But dragging from a views textfield to the Cocoa omnibox does not. (It should paste-and-go). I think this specific use-case is a bit obscure. But! the views-browser omnibox does not paste-and-go when dragging text. It just inserts text. We might want to treat that as a views-brower regression on Mac.
,
Apr 3 2018
** Bulk Edit ** There is only one dev release left 04/10 before M67 branch on 04/12. Please try to land the fix ASAP to trunk so we can move forward with 50%-50% experiment on M67 Canary/Dev (if possible at all). Thank you. FYI: Change/Fix has to be landed in trunk latest by 4:00 PM PT, Friday (04/06) so we can pick it up for next week dev release.
,
Apr 3 2018
ellyjones@, could you ptal and assign to appropriate dev as this is targeted for M67?
,
Apr 3 2018
MacViews triage: to spqchan@ for M68.
,
Apr 25 2018
Pls mark the bug as fixed if CL is landed in trunk and nothing else is pending. Thank you.
,
May 7 2018
,
May 29 2018
,
May 30 2018
macviews triage: to robliao@ - I don't think we care about views -> cocoa drag, but the views omnibox not navigating on drag is a bug.
,
May 30 2018
Turns out, on Windows, the default behavior is to paste the text into the Omnibox. No navigation or automatic search occurs. Is this something we really want on Mac?
,
May 30 2018
FYI, we changed this behavior on Views intentionally to never auto-search for text dragged directly to the omnibox for bug 791259 .
,
May 30 2018
Based off of #12 and bug 791259 , WontFix sounds like the correct resolution. Feel free to reopen if this is not the case.
,
May 30 2018
And for the record, the paste behavior does work on Mac. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by vineetha...@etouch.net
, Apr 3 20188.4 MB
8.4 MB View Download