Bug 172745
| Summary: | [Mac] Web content unable to properly prevent cursor auto-hiding on macOS | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Birunthan Mohanathas <birunthan> |
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ap, mitz, rniwa, wenson_hsieh |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.chromium.org/p/chromium/issues/detail?id=713202 | ||
Birunthan Mohanathas
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
> 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
(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