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

Issue 854939 link

Starred by 2 users
Status: Assigned
Owner:
a...@chromium.org
Cc:
nyerramilli@chromium.org
rbasuvula@chromium.org
█ ramyan@chromium.org
pkasting@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

I-Beam pointer is seen while dragging and dropping the NTP.

Reported by shruti.j...@etouch.net, Jun 21 2018 
Chrome Version: 69.0.3466.0 (Official Build) 7a22a4a62948746c970b84f31b1f78cd2cb3a1c2-refs/branch-heads/3466@{#1} (32/64 bit) 
OS: Mac (10.12.6, 10.13.1, 10.13.5, 10.13.6)

Pre-Condition:Enable 'Use Views browser windows instead of Cocoa' from chrome://flags.


Steps to reproduce:
1.Launch chrome and open NTP.
2.Drag and Drop back the tab.
3.Observe the Arrow pointer while dragging and dropping the NTP.

Actual Result : I-Beam pointer is seen while dragging and dropping the NTP.
Expected Result :Arrow pointer should be seen while dragging and dropping the NTP.

This is a Non-regression issue seen from ‘M-67’ series(#67.0.3381.0) .

Note:Issue is not seen on Windows(7,8,8.1,10) AND Linux(14.04 LTS).

Kindly review the attached screen-cast .

Thank You!
Actual_Result.mov
1.7 MB View Download
Expected_Result.mov
3.1 MB View Download

Comment 1 by rbasuvula@chromium.org, Jun 21 2018

Status: Untriaged (was: Unconfirmed)
As this being a Non-Regression issue, changing the status to Untriaged so that the issue would get addressed.

Thank You!

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

Owner: ellyjo...@chromium.org
Status: Assigned (was: Untriaged)
Over to ellyjones@ based on similarity to  Issue 832541

Comment 3 by twelling...@chromium.org, Jun 26 2018

Labels: zine-triaged

Comment 4 by ellyjo...@chromium.org, Aug 1

Owner: a...@chromium.org
avi, you know about cursors, right? :)

Comment 5 by ellyjo...@chromium.org, Aug 1

Labels: -M-69 -Target-69 Target-70 M-70
Target for M70 though

Comment 6 by a...@chromium.org, Aug 6 

What's happening here is interesting.

While a drag is happening over the same window, no cursor setting takes place. As soon as the drag tears off the tab, whatever mechanism was preventing the cursor setting turns off, and a slew of cursor setting calls happen, tracking the mouse pointer over the original window. No cursor setting happens, though, since the original window isn't key or main.

Then, when the tab merges back, the original window's cursor setting calls become functional again.

The question is: how does the original window track the pointer for avoidance of cursor setting, and how to we bounce that between the windows?

Comment 7 by a...@chromium.org, Aug 6 

Also, if you drag a window around by a tab, you seem to get mouse moved events. I'm not sure that's right.

Comment 8 by ramyan@chromium.org, Aug 22

Cc: ramyan@chromium.org
Components: -UI>Browser>NewTabPage UI>Browser>TabStrip UI>Browser
I can't repro on 69.0.3497.42 (Beta), but moving this to components that are more appropriate than NTP.

Comment 9 by shruti.j...@etouch.net, Aug 27 

WRT Comment#8:
Issue is reproducible on Latest canary M&)#70.0.3534.0 on OS: Mac (10.12.6, 10.13.1, 10.13.5, 10.13.6) .
Kindly refer the attached screen cast
Thank You!
Canary_Behaviour#70.0.3534.0.mov
4.4 MB View Download

Comment 10 by rp...@etouch.net, Nov 14

Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
"Mass UI Triage" update :
Rechecked the above issue on Mac OS X(10.13.1,10.13.6,10.14.2) using latest Canary build : 72.0.3610.0 and the issue is still reproducible.

@avi : Could you please take a look in to this issue.

Thank you..!!
Canary_behavior.mov
2.9 MB View Download
►

Sign in to add a comment