Update:
Providing per-revision bisect info:
You are probably looking for a change made after 565668 (known good), but no later than 565669 (first known bad).

CHANGE-LOG 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/2d21d004fa5157a1c4409b19e2f808001d026304..dd63892ee36e7faf92005f33cb0a1ec6cf10ecbd

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

Thank You!

Elly, I found the same problem in the "Save password?" bubble. The cursor doesn't change if the widget doesn't have focus. On Linux it works as expected. Is it a known problem already?

Does this repro on Cocoa?

With respect to comment #5:
Issue is also reproducible when cocoa flag is enabled.
Kindly refer the Attached screen-cast for your reference.
Thank You!

Deleted: Canary_Behaviou#69.0.3466.0..mov 2.1 MB

	Canary_Behaviou#69.0.3466.0..mov 2.1 MB View Download

We ignore the flag and always use Views. In native Cocoa UI this bug didn't exist.

The NextAction date has arrived: 2018-07-06

This is the usual behavior on Mac (i.e., cursor updates only happen in the active widget). In this case activating the generate password widget seems like a bad idea though. Perhaps we need some support in Views for doing this, like menus do with their local event tap for mouse events.

tapted@, any ideas?

Cursor updating isn't working in the omnibox results dropdown. It's almost certainly the same issue. Here's what I've found.

Inside of Views, during event handling, Views decides on a cursor to show, and calls Widget::SetCursor() to set it. On the Mac, that winds its way through various functions until it ends up in -[ViewsNSWindowDelegate setCursor:].

-[ViewsNSWindowDelegate setCursor:] holds onto the cursor in a local ivar, and then calls -[NSWindow resetCursorRects]. Eventually, the call to -[NSResponder cursorUpdate:] comes in, and -[NativeWidgetMacNSWindow cursorUpdate:]'s implementation asks the ViewsNSWindowDelegate for the cursor and sets it.

This works great for the main browser window. However, for the omnibox results dropdown and probably for the password widget, the call to -[NSResponder cursorUpdate:] never comes in and thus the cursor is never set.

I'm trying to track the resetCursorRects call. First, the docs explicitly say to never call it, so that's... great. Second, when is a cursor rect established for MacViews windows? I can't find any -[NSView addCursorRect:cursor:] calls in MacViews code.

Third, why doesn't -[ViewsNSWindowDelegate setCursor:] just set the cursor rather than play the game of letting -[NativeWidgetMacNSWindow cursorUpdate:] do it?

Ah, this was done in 715cb510d3fe596bf604c2e48741fbc08d1e9aee in 2015 by... you, Trent. Definitely your bug.

I'll try to get to this after  Issue 860362 .

At a glance, and based on "The cursor doesn't change if the widget doesn't have focus.", this may be as simple as tweaking the tracking area flags in BridgedContentView. It has

    // Apple's documentation says that NSTrackingActiveAlways is incompatible
    // with NSTrackingCursorUpdate, so use NSTrackingActiveInActiveApp.
    cursorTrackingArea_.reset([[CrTrackingArea alloc]
        initWithRect:NSZeroRect
             options:NSTrackingMouseMoved | NSTrackingCursorUpdate |
                     NSTrackingActiveInActiveApp | NSTrackingInVisibleRect |
                     NSTrackingMouseEnteredAndExited

NSTrackingActiveInActiveApp should be catering for what we want already :/. The documentation for NSTrackingActiveAlways says "The owner receives messages regardless of first-responder status, window status, or application status. The cursorUpdate: message is not sent when the NSTrackingCursorUpdate option is specified along with this constant. This value specifies when the tracking area defined by an NSTrackingArea object is active."

But maybe there's some technique that will make it work :/


wrt r314660, it was a while ago... (and that CL was not exactly fun..). I suspect -[ViewsNSWindowDelegate setCursor:] can't just call [NSCursor set] because there is no hook to *unset* the cursor when the mouse leaves the tracking rectangle.

The CL description and https://codereview.chromium.org/891003004#msg2 may be enlightening,

E.g.,

"RenderWidgetViewMac uses cursorRects, but it seems pretty buggy. E.g. click a
link and drag over the link text and the cursor flickers. Managing these cursor
rects is complicated, and even updating the cursorRect while the cursor is
"inside" the view, seems like a dead end. The approach here avoids simply
mashing [NSCursor set] on every mouse event, which seems to be what content
does."


So.. maybe we can "fix" this by mashing [NSCursor set], but that may expose us to this "flickering" in some cases.

However, since I wrote that quote above, src/content seems to avoid this flickering by creating a drag image for the link href (or maybe AppKit is providing that automatically in newer OSes..).

I'm doing some investigating. -[BridgedContentView initWithView:] is definitely setting up a tracking area.

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

commit 31de41a5cd7078ec8bc0b8bbb2dc82543a59f217
Author: Avi Drissman <avi@chromium.org>
Date: Wed Jul 11 23:54:41 2018

Fix the mouse pointer for the omnibox.

While the results pane is showing, forward cursor requests to the
underlying omnibox.

Note that this won't actually show any changes until 851834 is fixed.

BUG= 836829 , 851834 

Change-Id: I9928fe8f690cc27f1844dbe1c0b3dae08082706d
Reviewed-on: https://chromium-review.googlesource.com/1130167
Commit-Queue: Avi Drissman <avi@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574416}
[modify] https://crrev.com/31de41a5cd7078ec8bc0b8bbb2dc82543a59f217/chrome/browser/ui/views/omnibox/rounded_omnibox_results_frame.cc

Update:

Rechecked the above issue on Mac OS X(10.12.6,10.13.1,10.13.6) using latest canary build#69.0.3489.0 and issue is still reproducible.
Please find below attachment for reference.

Thank You...

Deleted: Canary Behaviour.mov 2.7 MB

	Canary Behaviour.mov 2.7 MB View Download

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

commit 2da5a6dc141b85cf9c8734a57bf1fba4506039c2
Author: Avi Drissman <avi@chromium.org>
Date: Mon Jul 16 15:36:29 2018

Fix cursors for child windows.

NSTrackingCursorUpdate only triggers the -cursorUpdate: message
for key windows. If MacViews tries to set a cursor for a non-
key window that is the child of a key window, set the cursor
manually.

BUG= 851834 

Change-Id: I91fe5eb1bc4880d847799e2e1f3bb0a1eb140d5a
Reviewed-on: https://chromium-review.googlesource.com/1135718
Reviewed-by: Trent Apted <tapted@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575279}
[modify] https://crrev.com/2da5a6dc141b85cf9c8734a57bf1fba4506039c2/ui/views/cocoa/views_nswindow_delegate.mm

This should fix this. Please verify.

Update:

Rechecked the above issue on latest canary version 69.0.3494.0 for Mac (10.12.6, 10.13.1, 10.13.6) OS and the issue is found Fixed. Hence, adding TE-verified labels.

Please refer the attached screen-cast.

Thank You..!!

Deleted: 69.0.3494.0_Fixed Video.mov 4.3 MB

	69.0.3494.0_Fixed Video.mov 4.3 MB View Download