[MacViews] Hover is hanging, when we move cursor outside of browser window.
Reported by
art-sn...@yandex-team.ru,
Oct 27 2016
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0 Steps to reproduce the problem: 1. Open two tabs 2. Drag one tab 3. Move cursor on control, beside of browser border. (Hover should be shown) 4. Move cursor outside of browser window. Video with steps: https://drive.google.com/open?id=0BzWfMBOuik2QZ043alNDVExpYTg What is the expected behavior? Hover should be hidden. What went wrong? Some times hover is hanging. Did this work before? No Chrome version: 1c90fa12b7708c99593724f2686aa9ceace52a60-refs/heads/master@{#425986} Channel: canary OS Version: OS X 10.11 Flash Version: The views::Widget not receive the mouse exit event in this case.
,
Oct 28 2016
> a different a different problem/bug/issue/weirdness that is. To fix this, I think we should try moving most of [BaseView mouseUp:] into a separate method like [BaseView clearDragWithEvent:]. Then call this from -[BridgedContentView processCapturedMouseEvent:] when it sees a [theEvent type] == NSMouseUp But see how you go with NSTrackingMouseEnteredAndExited first.
,
Oct 31 2016
Nothing changed after addition of NSTrackingMouseEnteredAndExited line. Bug video: https://drive.google.com/file/d/0BzWfMBOuik2QUmRETlhtNDUxSVU/view?usp=sharing
,
Oct 31 2016
You're conflating two issues. We still need NSTrackingMouseEnteredAndExited - without it this bug reproduces *without* steps 1. and 2. NSTrackingMouseEnteredAndExited is the right fix for that. And, once we are using that, we shouldn't need the complexity that you're adding to BridgedNativeWidget at https://codereview.chromium.org/2448173002/diff/60001/ui/views/cocoa/bridged_native_widget.mm#newcode1100 . That hit testing should be the job of the tracking area. _Then_ if we still need a step to clear out drag state in BaseView, then we can explore a simpler fix.
,
Nov 2 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eb34893a38b1baaef95c1f1d4e17e0c774794f43 commit eb34893a38b1baaef95c1f1d4e17e0c774794f43 Author: art-snake <art-snake@yandex-team.ru> Date: Wed Nov 02 23:38:47 2016 MacViews: Fix receiving of mouseexit events. BUG= 659959 R=tapted@chromium.org Review-Url: https://codereview.chromium.org/2466263006 Cr-Commit-Position: refs/heads/master@{#429454} [modify] https://crrev.com/eb34893a38b1baaef95c1f1d4e17e0c774794f43/ui/views/cocoa/bridged_content_view.mm
,
Aug 21
Fixing invalid statuses (no owner but not marked as available).
,
Nov 21
***Mass UI Triage*** This is working fine on the latest canary #72.0.3616.0 on Mac OS 10.13.6. If you feel this issue should need further action, please reopen it or file a new issue. |
|||
►
Sign in to add a comment |
|||
Comment 1 by tapted@chromium.org
, Oct 28 2016Thanks for the bug report! I can repro this without steps 1. and 2. I think the fix is just to add NSTrackingMouseEnteredAndExited in briged_content_view.mm at cursorTrackingArea_.reset([[CrTrackingArea alloc] initWithRect:NSZeroRect options:NSTrackingMouseMoved | NSTrackingCursorUpdate | NSTrackingActiveInActiveApp | NSTrackingInVisibleRect | > NSTrackingMouseEnteredAndExited It's likely there's a different with BaseView::dragging. Let's address that separately.