New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 646792 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Blocking:
issue 603373



Sign in to add a comment

[MacViews] First click event (in another control) after a Drag & Drop is ignored (also hover breaks)

Reported by art-sn...@yandex-team.ru, Sep 14 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0

Steps to reproduce the problem:
1. Show bookmark bar.
2. Drag any bookmark.
3. move mouse on tab/new tab button/settings button.

What is the expected behavior?
Control should be hovered.

What went wrong?
Control is not hovered

Did this work before? No 

Chrome version: 769c7abaea02b8e2e401ab43031aa68e211aaf0e-refs/heads/master@{#417640}  Channel: dev
OS Version: 10.10
Flash Version: Shockwave Flash 23.0 r0

This issue actual for all controls in browser ui.
 
screencast_2016-09-14_13-59-31.mp4
979 KB View Download
Also this Drag&Drop break the first click on any control (include controls in web content). Only second click has effect.
screencast 2016-09-14 15-00-39.mp4
2.0 MB View Download

Comment 2 by meh...@chromium.org, Sep 14 2016

Labels: Proj-MacViews

Comment 3 by tapted@chromium.org, Sep 15 2016

Blocking: 603373
Cc: tapted@chromium.org
Components: Internals>Views
Labels: Phase2
Owner: spqc...@chromium.org
Status: Assigned (was: Unconfirmed)
Summary: [MacViews] First click event (in another control) after a Drag & Drop is ignored (also hover breaks) (was: [MacViews] Hovering is not working)
Sarah - can you take a look? There's probably some FooFocus() call that needs to be done after a FooEndDrag(). Repro steps in Canary:

0) chrome://flags/#mac-views-webui-dialogs enabled
1) Go to https://httpbin.org/basic-auth/user/passwd
2) Type "one two" in the User Name field
3) Select "two" and drag the selection to before the "one"
4) Click in the password field.

Expected: password field should get focus.
Actual: focus stays in user name field.
I'm a bit concerned how the fix is making changes to ui/base/cocoa/base_view.h since that's being used outside of MacViews.
I think this original change to base_view is outdated by now and no longer needed. 
Original changes: http://codereview.chromium.org/1774014
Now, I can not reproduce BUG= 33100 , without original changes.

May continue discussion in https://codereview.chromium.org/2337233004 ?

Project Member

Comment 7 by bugdroid1@chromium.org, Sep 26 2016

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

commit 48134b46f0a22980774d9b9cb074e04b4971ada5
Author: art-snake <art-snake@yandex-team.ru>
Date: Mon Sep 26 17:51:36 2016

MacViews: Fix sending mouse exit event and releasing capture on D&D.

Currently, clicks immediately after a drag in a MacViews window are
ignored. This is because initiating a drag and drop session with
-[NSView beginDraggingSessionWithItems:..] suppresses the mouse events
that would result in capture being released. To fix, explicitly release
Widget capture before starting the dragging session.

BUG= 646792 

Review-Url: https://codereview.chromium.org/2337233004
Cr-Commit-Position: refs/heads/master@{#420925}

[modify] https://crrev.com/48134b46f0a22980774d9b9cb074e04b4971ada5/ui/views/cocoa/drag_drop_client_mac.mm
[modify] https://crrev.com/48134b46f0a22980774d9b9cb074e04b4971ada5/ui/views/cocoa/drag_drop_client_mac_unittest.mm

Comment 8 by tapted@chromium.org, Sep 26 2016

Cc: spqc...@chromium.org art-sn...@yandex-team.ru
Owner: ----
Status: Fixed (was: Assigned)

Sign in to add a comment