Note: Issue is not seen on Linux OS.

Correction in chrome Version: Chrome Version: 62.0.3175.0 Revision 01f38b46d3446cc7ae3f482d59dbc1841f625479-refs/heads/master@{#491592}(64bit)

Using the per-revision bisect providing the bisect results,
Good build:62.0.3168.0(Revision:489803).
Bad build:62.0.3169.0(Revision:490187).

You are probably looking for a change made after 489888 (known good), but no later than 489889 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/4cd89cf9e58a8ac501120cf79363b47c8967d0fc..198152e00f3cce3cbfd834febe2636e80e4a9670

From the CL above, assigning the issue to the concern owner

@jgruber : Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Reviewed-On:https://chromium-review.googlesource.com/588888
Note :Mac specific issue and Able to reproduce in latest Canary #62.0.3175.0

My CL only sets a few test expectations to NeedsManualRebaseline. Sorry, no idea about a relevant owner. Assigning back for further triaging.

hughoh@ could this be caused by your changes? Sounds related.

I don't think it is. 

My change allows you to avoid an unnecessary I-beam by setting "user-select: none". 

That works if the UI is HTML of course :) Here, I don't know if Zoom + and - buttons are in HTML... Looks like they are made of the OS' native UI drawing? I suggest you assign this to someone who has experience of Mac's (native) UI.

But Comment #2 suggests that this is already fixed? If yes, just close as WontFix.

I don't think this is any of Blink issue.

As far as I observed, the mouse pointer, which should be arrow-shaped,
sometimes changes to I-beam while clicking on zoom + or - button.
I'm not sure opening the print dialog is necessary to reproduce the issue,
but I can reproduce with canary (62.0.3178.0) on Mac OSX, with a print dialog is open.
I cannot reproduce without print dialog open, with a few retries.

It smells that the issue is related to how browser-side UI code handles focused UI
element, and how it propagates the state into mouse pointer icon.

Moving the components to UI for further triage on the browser process side.

Unable to provide the per revision bisect as getting wrong culprits.So providing the manual bisect.

Log File: https://chromium.googlesource.com/chromium/src/+log/62.0.3168.0..62.0.3169.0?pretty=fuller&n=10000

Change Log: https://chromium.googlesource.com/chromium/src/+/656f9b939150e9a40553757cea46d385bcb423d9

@nzolghadr: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-URL:  https://codereview.chromium.org/2973963003

Thank You!


 

It definitely doesn't have anything to do with my change. chaopeng@ can you double check whether this is affected by your recent CL for the cursor change? I know it is unlikely as your change was inside the Blink but anyway. Please assign back to the  rbasuvula@ if it is not related to yours. 

Sorry, I can not reproduce this issue on my mac (10.12.6)
tried version: 

Canary 62.0.3182.0
Debug e4aa73e1d87f2a8253311b61e479589c2d7ededa 62.0.3169.0 last commit for 62.0.3169.0
Debug 1b5b36fd2dcb4fa11d6453da1189be00e9cc892d 62.0.3168.0 last commit for 62.0.3168.0

Also I don't think it related to my recent changes.

@ dbote : Could you please check once in latest canary and provide the observations.

Thank You!

With respect to comment12:

Issue is still reproducible on Mac (10.12.3, 10.12.5, 10.11.6) using latest build #63.0.3212.0

Please find the attached screen cast for the same.

Deleted: Actual_Issue.mov 4.9 MB

Actual_Issue.mov 4.9 MB Download

rbasuvula@ could you revert the changes I made in html.css and verify if you that fixes the problem? I don't have a Mac myself to try this on. 

I talk about re-adding these 4 lines:

https://chromium-review.googlesource.com/c/chromium/src/+/570246/16/third_party/WebKit/Source/core/css/html.css

If that worked, which one of those 4 lines fixed it?

This still repros on trunk. The repro steps are:

1) Navigate to chrome://version
2) Cmd-P to print
3) Via the dots menu, click the zoom "+" a bunch of times

The cursor for the menu will sometimes change to an i-beam depending on whether text in the underlying WebContents is under where the mouse cursor is. I don't understand why step 2 is necessary. Over to avi@ - the symptom here is Pri-3 but I think this suggests something weird/wrong in our menu code.

***Mass UI Triage***

Rechecked the above issue on Mac(10.13.6,10.14.1,10.13.1) using latest Canary build : 72.0.3610.2 and the issue is not reproducible.If this bug still reproduces for you, please reopen or file a new issue. 

Thanks!