Safari hides the cursor for most keys if `event.preventDefault()` is called: https://github.com/WebKit/webkit/blob/dfc70eed6820b5c5c1fac1fecfd3e4e4dbfdee8f/Source/WebKit2/UIProcess/Cocoa/WebViewImpl.mm#L4220 For some other keys (e.g. Escape), the default behaviour always hides the cursor: https://github.com/WebKit/webkit/blob/5277f6fb92b0c03958265d24a7692142f7bdeaf8/Source/WebKit/mac/WebView/WebFrameView.mm#L1095 This means that web content is unable to *both* prevent the default behaviour *and* keep the cursor visible. This is problematic for e.g. design tools, which rely heavily on a keyboard centric workflow with many shortcuts for which the default behaviour needs to be prevented. Chrome had a similar issue, see https://bugs.chromium.org/p/chromium/issues/detail?id=713202 The Chrome solution was to hide the cursor on input only if a textual input type is in focus. Firefox is planning a similar fix. Ideally Safari should match the other browsers for web compatibility.
> The Chrome solution was to hide the cursor on input only if a textual input type is in focus. This sounds like it has the potential to introduce incorrect behavior on advanced text editors (I suggest testing Pages for iCloud).
(In reply to Alexey Proskuryakov from comment #1) > > The Chrome solution was to hide the cursor on input only if a textual input type is in focus. > > This sounds like it has the potential to introduce incorrect behavior on > advanced text editors (I suggest testing Pages for iCloud). It works fine and as expected in both Google Docs and Pages for iCloud. Can you elaborate what you meant by incorrect behavior? FWIW, both Docs and Pages focus a contenteditable element to receive text input. Note that Chrome considers contenteditable elements to be a textual input type as well: https://cs.chromium.org/chromium/src/ui/base/ime/text_input_type.h?rcl=2150a498ab8ba74261d142941533992fb21bd2d8&l=15