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

Issue 854856 link

Starred by 6 users

Issue metadata

Status: Verified
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Cursor locked after right clicks

Project Member Reported by amineer@chromium.org, Jun 21 2018

Issue description

Chrome Version: 69.0.3464.2 (dev)
OS: 10.13.5

What steps will reproduce the problem?
(1) Open a webpage
(2) Right click on Chrome UI (e.g. bookmarks bar on a folder)
(3) Click outside the dialog (don't actually do anything)
(4) Hover mouse over a link on current webpage

What is the expected result?
Cursor turns to pointer

What happens instead?
Cursor remains default, doesn't indicate clickable link

Might be new with MacViews, since it started after a recent Chrome relaunch and the context dialogs look different now?  This is pretty visible / annoying so tagging as dev blocker but feel free to change if disagree.

 
Also this is affecting other app behavior (e.g. in Inbox, after triggering bug, hovering over e-mails doesn't show the option to mark as done, snooze, etc)

Comment 2 by gov...@chromium.org, Jun 21 2018

Cc: robliao@chromium.org manoranj...@chromium.org
Labels: M-69 Proj-MacViews MacViews-Browser

Comment 3 by ajha@chromium.org, Jun 21 2018

Components: Internals>Views>Desktop
Just to update, this is MacViews specific issue and similar behavior is seen on the latest stable: 67.0.3396.87 as well, on Mac OS 10.13.3 by enabling 'views-browser-windows' flag. 
Labels: -ReleaseBlock-Dev ReleaseBlock-Beta
Upon further reflection this probably isn't a dev blocker but I do think it's annoying enough for beta (and I would still prefer a quicker dev fix).
Labels: -Pri-1 Pri-2
Owner: ellyjo...@chromium.org
Status: Assigned (was: Untriaged)

Comment 6 by gov...@chromium.org, Jun 21 2018

Cc: markchang@chromium.org
Will this be a blocker for M68 Beta 50% experiment if we decide to do?

Comment 7 by tapted@chromium.org, Jun 22 2018

Cc: ellyjo...@chromium.org
Owner: tapted@chromium.org
Status: Started (was: Assigned)
pretty sure this is just https://chromium-review.googlesource.com/1111486
Project Member

Comment 8 by bugdroid1@chromium.org, Jun 22 2018

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

commit 67221b27f38f964cf0d5b8fa8389c12a2bf79a5a
Author: Trent Apted <tapted@chromium.org>
Date: Fri Jun 22 05:49:00 2018

Views+CocoaMouseCapture: Don't capture MouseEntered/Exited events

toolkit-views has a concept of Capture to funnel mouse events to things
like menus (compared to Cocoa's nested event-tracking loops).

Currently all event types are funelled, but taking entered/exit events
away from native NSViews breaks their tracking area logic. In fact,
toolkit-views Capture does not need entered/exit events for tracking
areas on other windows, just its own (which it doesn't need capture for).

Bug:  854856 
Change-Id: I86de2fd8c444d47bf37ce7ca69903081f10af523
Reviewed-on: https://chromium-review.googlesource.com/1111486
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569537}
[modify] https://crrev.com/67221b27f38f964cf0d5b8fa8389c12a2bf79a5a/ui/views/cocoa/cocoa_mouse_capture.mm

Comment 9 by gov...@chromium.org, Jun 22 2018


+manoranjanr@ to verify this bug on next canary.
Labels: TE-Verified-M69 TE-Verified-69.0.3472.0
Able to reproduce the issue on Mac 10.13.3 using chrome version without fix.

Verified the fix on Mac 10.13.3 using Chrome version #69.0.3472.0 as per the comment #0.
Attaching screen cast for reference.
Observed that cursor turned to pointer.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!
854856.mp4
1.0 MB View Download
Status: Verified (was: Started)

Sign in to add a comment