* Moved the default BinaryMessenger instance to ServicesBinding
This reverts commit 821602aef36983d416836e5d6fcc78fe9d3facb1.
* Added assertion in defaultBinaryMessenger. Also fixed the devicelab tests.
Flutter widget tests assert if a test completes with timers still
pending. However, it can be hard to diagnose where a pending timer
came from. For example, a widget might consume a third-party library
that internally uses a timer.
I added a FakeAsync.pendingTimersDebugInfo getter to quiver
(https://github.com/google/quiver-dart/pull/500). Make flutter_test
use it.
Additionally modify Flutter's debugPrintStack to take an optional
StackTrace argument instead of always printing StackTrace.current.
Fixes#4237.
* Add an 'unfocusable' focus node to allow developers to indicate when they don't want a Focus widget to be active
* more unfocusable changes. not working.
* Switch to focusable attribute
* Rename to canRequestFocus
* Turn off debug output
* Update docs
* Removed unused import
In another change (#37646), I want to test that a test fails and
prints expected output. I didn't see an existing way to do that, so
I modified `_runFlutterTest` and `runCommand` to allow capturing the
output. Currently capturing and printing output are mutually
exclusive since we don't need both.
Some awkward bits:
* There already exists a `runAndGetStdout` function that is very
similar to `runCommand`, and this change makes the conceptual
distinction more confusing.
* `runFlutterTest` has multiple code paths for different
configurations. I don't understand what the different paths are
for, and I added output checking only along one of them.
* Add a test for a directory instead of a single test.
* Add test data to a child directory to test the command.
* Add test data to a child directory to test the command.
* Add test data to a child directory to test the command.
* Correct test.
This reverts commit 92ef2b9ce1d4e54d5efb3e6a962e9e724dc7efeb.
This requires either runApp() or
WidgetsFlutterBinding.ensureInitialized() to have been called before
using any MethodChannels. Plugins broadly rely on MethodChannels and
right now there's no general requirements that they be constructed
within the runApp call, so the ecosystem breakages from this are broader
than originally thought. Reverting for now.
