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

Issue 762379 link

Starred by 5 users
Status: WontFix
Owner:
dtapu...@chromium.org
Closed: Jan 3
Cc:
█ divya.pa...@techmahindra.com
erikc...@chromium.org
█ shrike@chromium.org
█ msta...@mozilla.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug-Regression


Participants' hotlists:
Hotlist-1


Sign in to add a comment

Regression: cursor no longer autohides on keydown after https://crrev.com/467012

Reported by bra...@gmail.com, Sep 6 2017 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce the problem:
1. Open any web page in Chrome/Chromium.
2. Click in the page so the cursor's focus is *not* in a text box.
3. Press any key. In particular, try arrows or space.

What is the expected behavior?
Cursor should disappear immediately.

Keydown events when the focus is in the web view, not just text fields, should hide the cursor. This is the standard macOS behavior in other browsers like Safari and Firefox and macOS apps in general.

This becomes a nuisance when trying to read text or watch videos and there's no good place to "hide" the cursor.

What went wrong?
Cursor does not disappear.

Did this work before? Yes mac chromium snapshot 467003

Chrome version: 60.0.3112.113  Channel: n/a
OS Version: OS X 10.11.6
Flash Version: 

This regression appears to have been (deliberately?) caused by https://crrev.com/467012. Looking at the commit message, I would urge this commit be reverted in favor of some other resolution to the referenced bug ( issue 713202 ). Refusing to hide the cursor on any keydown and thereby breaking the standard expected conventions for macOS browsers and apps shouldn't be an acceptable compromise here. Either the original bug was invalid, or there is another solution that other browsers are using for it.

Comment 1 by divya.pa...@techmahindra.com, Sep 6 2017

Cc: divya.pa...@techmahindra.com
Components: -UI Blink
Labels: -Pri-2 Needs-Triage-M60 Triaged-ET M-63 Pri-1
Owner: dtapu...@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on 60.0.3112.113 stable and latest canary 63.0.3207.0 using Mac 10.12.6.

Manual Bisect Info:
===================
Good Build:60.0.3080.0
Bad Build: 60.0.3081.6

As per the comment#0 Suspecting https://crrev.com/467012

@dtapuska: Could you please check and confirm the behavior and help in reassigning if not related to your change.

Thanks!

Comment 2 by divya.pa...@techmahindra.com, Sep 6 2017

Labels: hasbisect

Comment 3 by dtapu...@chromium.org, Sep 6 2017

Cc: erikc...@chromium.org msta...@mozilla.com shrike@chromium.org
Components: -Blink Blink>Input
Labels: -Pri-1 Hotlist-Input-Dev Pri-2
All: As we decided on  issue 713202  there appears to be one user whom feels this is uncomfortable. I'll try reaching out to Safari folks.

Comment 4 by shrike@chromium.org, Sep 6 2017 

I don't see this autohide behavior in Safari. For example, if I simply go to the Apple home page the cursor does not hide (except for the space bar - the cursor hides the first time you press it, which scrolls the page, but does not hide upon subsequent presses).

Comment 5 by dtapu...@chromium.org, Sep 6 2017 

shrike@ I see that too. There are definitely inconsistencies in this on Safari.

Comment 6 by bra...@gmail.com, Sep 6 2017 

I did a little more testing in Safari, and it looks like the cursor hides not necessarily on every keydown (though I'm pretty sure it used to) but rather when a keydown would cause the view to scroll in some direction. Arrow keys, space, page up, page down, home, and end all exhibit this behavior in Safari on apple.com, for example.

Comment 7 by mustaq@chromium.org, Jan 3

Labels: -Pri-2 Pri-3
Status: WontFix (was: Assigned)
I see two possibilities here: autohide on keyboard-scrolling only, or no autohide at all (as of today).  I am closing the bug as WAI because we didn't get any other complains with the current behavior, plus this doesn't have any impact on usability.
►

Sign in to add a comment