slate: iOS Safari: Double-tapping the space bar doesn't insert a period
Do you want to request a feature or report a bug?
bug
What’s the current behavior?
Even when iOS’s ‘“.” Shortcut’ keyboard setting is enabled, double-tapping the spacebar in Slate doesn’t insert a period.
https://jsfiddle.net/rgrove/v0mkz2w0/4/
What’s the expected behavior?
When iOS’s ‘“.” Shortcut’ keyboard setting is enabled, double-tapping the spacebar should insert a period followed by a space, as it does in a <textarea> or a native text field.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 1
- Comments: 23 (21 by maintainers)
Commits related to this issue
- Revert the removal of isNative Preventing native text input events completely breaks autocorrect, autocomplete, auto-capitalization, predictive text, and double-space period insertion on iOS. In orde... — committed to rgrove/slate by rgrove 7 years ago
- Use native `beforeinput` events to handle text insertion when possible In browsers that support it (currently only Safari has full support), the native `beforeinput` DOM event provides much more usef... — committed to rgrove/slate by rgrove 7 years ago
- Use native `beforeinput` events to handle text insertion when possible (#1232) * Add support for finding a Slate range from a native StaticRange * Add a `SUPPORTED_EVENTS` environment constant ... — committed to ianstormtaylor/slate by rgrove 7 years ago
- Fix broken iOS UA sniff that identified iOS as macOS UA sniffing stops at the first match when trying to determine the client's OS. Since the macOS sniff always ran before the iOS sniff and matched t... — committed to rgrove/slate by rgrove 7 years ago
- Fix broken iOS UA sniff that identified iOS as macOS (#1365) UA sniffing stops at the first match when trying to determine the client's OS. Since the macOS sniff always ran before the iOS sniff and ... — committed to ianstormtaylor/slate by rgrove 7 years ago
@rgrove I think augmenting the current usage would be a good start, unless replacing is the only way to achieve what we want. I’m open to either solution there.
As for preventing the browser from inserting text—I don’t think we actually have to do this. The current
onInputhandling assumes that the browser has already inserted text, for example this is how the current spellcheck-handling behavior works. We could either let all of the input through, and backport the changes to the internal model. Or we could just expand the cases that let the input through, to handle these iOS cases, if there’s a way to discern them. (Potentially by using theevent.inputTypeflag.)It looks like this bug was introduced in #1088 with the removal of
isNative(which also caused #1176). Please see #1176 for more discussion of this issue.