WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
172745
[Mac] Web content unable to properly prevent cursor auto-hiding on macOS
https://bugs.webkit.org/show_bug.cgi?id=172745
Summary
[Mac] Web content unable to properly prevent cursor auto-hiding on macOS
Birunthan Mohanathas
Reported
2017-05-30 23:33:26 PDT
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
2017-05-31 22:19:31 PDT
> 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).
Birunthan Mohanathas
Comment 2
2017-05-31 23:27:54 PDT
(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
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug