* a11y: remove SemanticsSortOrder; sort locally only; semanticsOwner post-test check
* update accessibility test framework
- default nextNodeId/previousNodeId to -1
- stop treating null as opt-out from value testing
- add `id`, `TestSemantics.root`, and `tags` to the suggested code in the TestSemantics failure message
- fix a small bug with raw string escaping
- update all tests accordingly
* fix sortKey doc
* prefer const over final
**This PR contains a breaking API change:**
`SemanticsConfiguration.addAction()` has been removed and replaces by action-specific setters (`onTap`, `onLongPress`, etc.) to take care of the fact that some action handlers (those, who take arguments) have different signatures.
Since MethodCall equality checks are limited to test scenarios, this
patch replaces them with an equivalent test matcher. At present
MethodCalls are always used in scenarios where indentity-based
equality/hashing is appropriate.
This change avoids an assertion failure when MethodCall args are
Iterable (possible since args are of type dyanmic), and hashValue() from
dart:ui asserts that its input is not an Iterable.
The alternative of implementing support for deep equality in dart:ui was
rejected on the basis that if we're to encourage performant code,
expensive checks should be obviously-expensive to the author.
In 85c425ac88, a test was added to ensure that widget.onChanged was
fired when the contents of an EditableText changed via system paste
events (e.g. triggered from a TextSelectionOverlay). Due to a long stack
of rebases and (less-than-perfect) manual merge conflict merge
resolution, it was inadvertently added twice.
This patch fixes a collection of issues with widgets involved in text
editing:
* Fire widget.onChanged on EditableText value change:
The value of an EditableText is composed of the text value as well
as other editing-related data such as selection-related information.
Previously, widget.onChanged() was only called for updates via
updateEditingValue(). For pastes via a TextSelectionOverlay, updates
are signalled via _handleSelectionOverlayChanged(), which only ever
triggered widget.onSelectionChanged(), but not widget.onChanged().
Both updateEditingValue() and _handleSelectionOverlayChanged()
perform the value update via _formatAndSetValue(), which is where
this patch moves the widget.onChanged() call.
* Correctly update TextFormField value on edits via controller:
The textual value of a TextFormField exists in two locations:
1. FormField.value, as with all FormFields and subclasses.
2. TextEditingController.value associated with the TextField
underlying the TextFormField.
Previously, edits to the TextEditingController associated with a
TextFormField resulted in updates to the rendered TextField widget,
but did not update TextFormField.value. FormField.value is updated
via FormField's onChanged function, which is called from the
EditableText underlying the TextField underlying the TextFormField.
EditableText only fires onChanged when it receives changes from the
engine. It does not fire onChanged for changes made to the
underlying TextController, since the owner of the TextController is
the one making these changes and thus, already aware of them.
FormField, however, *does* need to listen to these changes to update
its value.
* Adds an initialValue parameter to the TextFormField constructor:
FormField's constructor already takes an initialValue parameter,
which specifies the initial value in the field, which is also the
value to which reset() returns the field.
Previously, TextFormField took its initial value from the controller
value (if a controller was passed in) or the empty string (if not).
This had the undesirable effect that calling reset() always resets
the value to the current value of the controller... i.e., does
nothing.
We now take an initial value explicitly.
Adds a test that verifies that EditableText sends a
TextInput.setEditingState message to the engine when the associated
TextEditingController is replaced.
