Two things come to mind:

1) Can we key the hiding of the cursor off the ack result of the keydown? It seems Safari does something like this. They allow the event to be dispatched and then look at the result. (https://github.com/WebKit/webkit/blob/4204c37ea44e511e136f1e80728ed0ea7d46803f/Source/WebKit2/UIProcess/Cocoa/WebViewImpl.mm#L4187) if I am reading their code right.

This creates a problem for pages that wish to preventDefault the action because the input event ack state isn't told about whether it was handled by the application or the default event handler. 

bir...@ does this actually work in Safari if you prevent the default action? Or do they have a bug too?

2) We could augment the shouldAutohideCursorForEvent (https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_mac.mm?q=render_widget_host_view_mac.mm+package:%5Echromium$&dr&l=2834)

with this code:

return (GetTextInputType() != TEXT_INPUT_TYPE_NONE &&
        [event type] == NSKeyDown &&
             !([event modifierFlags] & NSCommandKeyMask)) ? YES : NO;


The TextInputType changes when an input field has focus. This would hiding the cursor on navigation keys of the page.

It seems like Safari does indeed hide the cursor only if you call `event.preventDefault()`. It also seems like the default Safari handler for e.g. escape and page/up down always hides the cursor: https://github.com/WebKit/webkit/blob/382a078d779dc2d261648f8609b84d73b40c7cbb/Source/WebKit/mac/WebView/WebFrameView.mm#L1095

That is problematic because you have to choose between keeping the cursor visible and preventing the default behaviour for at least backspace, space, home, end, page up/down, and the arrow keys.

I think the 2) feels like a better solution. It also seems to be how e.g. Finder and Preview work.

I would personally be happy to contribute a patch to Firefox for 2). Maybe we can also convince WebKit to implement it.

What do you think?

+erikchen@ does the Chrome Mac team have an opinion?

+shrike, TL of the Mac team.

Is there a web spec for the appropriate behavior here? If not, I generally prefer to match Safari's behavior for better web compatibility. But if their behavior is also wrong, then perhaps we should indeed implement (2). It seems like someone needs to reach out to all three browser so we can come to an agreement about the right behavior and improve web compatibility. birunthan@, could you do that?

Only hiding the cursor if a text input field is focused (or if our default handler deems it appropriate) sounds good to me from the Firefox side.

bir...@ Can you help me understand the impact of this? ie; is something impacted that would be broken already in Safari?

Is this an annoyance of a current website?

We have to understand the benefit/cost of not doing this vs deviating from Safari's implementation.

dtapuska, yes, this is definitely an issue for our webapp. We're developing a vector design tool (www.figma.com, free to sign up if you want to try it out) similar to e.g. Sketch or Adobe Illustrator. Designers are used to a very keyboard-centric workflow so the auto-hiding cursor is especially problmatic for us. Like most design tools, we have many modifier free shortcuts like "r" to select the rectangle tool or "t" to select the text tool, but they currently hide the cursor. The worst offender is dragging the canvas while holding the spacebar down. This is the standard panning shortcut in design tools, but it currently results a flickering cursor as you drag the canvas.

We could avoid calling preventDefault() to resolve the issue (in Safari) for most keys. However, at least the keys listed in comment 3 will remain problematic.

For example, we use escape to cancel selections and dismiss menus. In a native macOS app, those actions do not affect the cursor. Safari's default escape handler, however, hides the cursor. Since calling preventDefault() *also* hides the cursor, we are stuck between a rock and a hard place.

The Safari behaviour is also undocumented and, at least to me, unexpected. I would expect a well-behaving application to call preventDefault() when it handles a shortcut. With Safari, you are expected to do the opposite if you want to keep the cursor visible.

I should also mention that Electron (a Chromium based framework for developing desktop apps) even patches Chromium to optionally disable the auto-hiding cursor: https://github.com/electron/libchromiumcontent/blob/f7c1f34a14ee366cb5013ba29f88227883fb9a28/patches/render_widget_host_view_mac.patch#L64

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

commit 32e2eec87fcd9c791791f4e67c76a85eab7f9ed8
Author: dtapuska <dtapuska@chromium.org>
Date: Tue Apr 25 16:35:10 2017

Only autohide the cursor when we are on a text entry field.

Previously we autohid the cursor whenever a keydown occurred. But this
presents issues for pages that don't want the cursor auto hidden but still
receive key events. Instead we are going to autohide the cursor when
there is a text input type set; which means the focus is inside a text
input entry field. The cursor will no longer autohide if you are scrolling
via the arrow keys but this seems like a reasonable tradeoff.

BUG= 713202 

Review-Url: https://codereview.chromium.org/2839813002
Cr-Commit-Position: refs/heads/master@{#467012}

[modify] https://crrev.com/32e2eec87fcd9c791791f4e67c76a85eab7f9ed8/content/browser/renderer_host/render_widget_host_view_mac.mm