Some keyboards (e.g., on some Samsung devices, SwiftKey) ignore
InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS and require
InputType.TYPE_TEXT_VARIATION_PASSWORD.
Previously, taps were sent to the topmost tap handler in the center of the accessibility frame of the selected element nd therefore might have been handled by a different element than the desired one.
**This is a breaking change on iOS**
Previously, the `paused` state was entered when the application resigned
active status. `inactive` now maps to this status. `paused` now maps to
an app that has been backgrounded.
`inactive` is currently emitted on iOS only and corresponds to iOS's
foreground inactive state.
Current state transitions are:
`resumed` <--> `inactive` <--> `paused`
suspending is currently emitted on Android only and corresponds to the
transition to Android's stopped state.
Current state transitions are:
`resumed` <--> `paused` --> `suspending` --> `resumed`
These transitions may change in future.
* Fix crash in iOS accessbility
Previously, whenever an action would remove the focused element from the screen the app would crash. This change tells iOS to focus the first on-screen element after every change to the semantics tree. This avoids the crash.
In a future iteration, we should tell iOS which element it needs to focus by looking at the sematnics tree (instead of leaving it up to the iOS).
* Better handle the case were the focused element stays on the screen
* review comments
Use AudioServicesPlaySystemSound instead of AudioServicesPlayAlertSound.
This avoids the potential of a system beep on devices without support
for haptic feedback.
Scrollable elements can now be scrolled in accessibility mode and they scroll in the right direction.
Note: App crashes right after scroll finishes (that's a separate problem as the app currently crashes after every action performed in accessibility mode).
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)
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
