Check incoming text editing state and only fire textWillChange:,
textDidChange:, selectionWillChange:, selectionDidChange: when the text
or selection actually changes.
On selectionWillChange: in a text field where auto-correct is enabled,
iOS will attempt to auto-correct the word preceding the cursor. This
change also updates the text before calling selectionWillChange: to
prevent auto-correction on the preceding value of the text field.
The core problem was multiplying matrices the wrong way around.
While I was there I did some minor cleanup. I think that may have
fixed another bug relating to A11Y turning on or off improperly, but
since I never figured out the steps to reproduce, it's hard to tell.
Fixes https://github.com/flutter/flutter/issues/7205
Fixes https://github.com/flutter/flutter/issues/10059 (maybe)
Having the device pixel ratio of the test shell be 1.0x makes it
unlikely that we will catch errors relating to mishandling of the
device pixel ratio in the test shell.
This patch arbitrarily increases the device pixel resolution while
keeping the logical resolution the same.
This change brings iOS return key behaviour in line with current behaviour on
Android.
* Implements TextInputClient.performAction for iOS Adds FlutterTextInputAction
* enum Defaults return key to 'Done' Ends editing and hides the keyboard if
* 'Done' is pressed
Future work is planned to support configurable return/action key behaviour.
See: #9573, #9210, #8028.
Previously, it was a static. Doesn't have much effect in practice because we
only use this microtask queue for main isolates, which exist on a single
thread.
Ensure that both self.text and self.selectedTextRange are updated before
triggering textDidChange: or selectionDidChange: on the input delegate
(which then re-computes positions). This prevents inconsistencies in
selection vs text position/offset lookups triggered by didChange
notifications.
Ensure that rangeOfComposedCharacterSequenceAtIndex: is only ever called
for index values > 0 && < self.text.length. This prevents such calls for
position with index == self.text.length.
Also reduces unnecessary textDidChange/selectionDidChange notifications:
replaceRange:withText: and setMarkedText:selectedRange: are only ever
called by UIKit and methods called by UIKit (insertText,
deleteBackward), so notification is unnecessary.
textContentType was added in iOS 10, and we target iOS 8. Either way the
framework doesn't (yet) include support for this; keyboard type covers
most bases.
Supports:
* autocorrect, suggestions view/selection.
* Support for Chinese, Japanese, Korean and other languages using
multi-stage input with candidate selection.
* styling the composing (mark) region for multi-stage input
* key-repeat when backspace held down
* physical and soft keyboard support for arrow key cursor movement and
selection.
* improved third-party keyboard support
Does not yet support:
* force-touch drag cursor positioning
* auto-positioning the candidates view for multi-stage input methods
when used with a physical keyboard (e.g., iPad Pro) currently
positioned at 0,0.
* voice dictation
