There were four or five different implementations in various tests for sendFakeKeyEvent, which roughly all did the same thing. I was going to add yet another one, and decided that it needed to be generalized and centralized. This replaces those instances with something that just takes a LogicalKeyboardKey so that it's self-documenting, and can be used with multiple platforms.
This adds two functions to widget tester: sendKeyDownEvent and sendKeyUpEvent which simulate key up/down from a physical keyboard. It also adds global functions simulateKeyDownEvent and simulateKeyUpEvent that can be called without a widget tester. All are async functions protected by the async guard.
* Fixing LocalFileComparator output
* Fixing path separators for windows failures
* Windows path issues
* Testing
* ++
* ++
* Fixing base directory - windows
* Clean up
* Minor improvements to framework documentation.
* maybePop documentation fix
* Mark some flutter_test arguments required.
Without these set, we get a crash.
* Minor correction to ListView docs
* WIP on web plugin registry
* WIP on registering plugins
* WIP on web plugin registration
* Only generate `package:flutter_web_plugins` imports if plugins are
defined
* Add parsing test
* Add documentation
* Fix analyzer warnings
* add license headers
* Add tests for package:flutter_web_plugins
* Run `flutter update-packages --force-upgrade`
* Fix analyzer errors
* Fix analyzer error in test
* Update copyright and remove flutter SDK constraints
* Enable tests since engine has rolled
* add flutter_web_plugins tests to bots
* Create an empty .packages file for WebFs test
* Moved the default BinaryMessenger instance to ServicesBinding
This reverts commit 821602aef3.
* 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.
Teach Layer and its implementations, RenderObject and its implementations, and PaintingContext to reuse engine layers. The idea is that a concrete RenderObject creates a Layer and holds on to it as long as it needs it (i.e. when it is composited, and the layer type does not change). In return, each Layer object holds on to an EngineLayer and reports it to the engine via addRetained and oldLayer. This allows the Web engine to reuse DOM elements across frames. Without it, each frame drops all previously rendered HTML and regenerates it from scratch.
* Broadcasting popRoute and pushRoute methods via SystemChannels.navigation. These messages will be used in flutter_web to detect the route
* Broadcasting popRoute and pushRoute methods via SystemChannels.navigation. These messages will be used in flutter_web to detect the route
* Reverting all unrelated formatting changes.
* Adding unit tests. Adding more comments.
* Changing string method names with constant strings.
* Fixing a constant strings.
* Fixing analyzer error.
* Fixing more white space.
* Changing the method names. Adding comments to the SystemChannels
* Comment and code name fixes
* replacing the comment with reviewer suggestion.
* addinf systemchannels.navigation mock to test bindings
* Adding a new class for sending route change notrifications. The nottifications are only sent on web. This should fix breaking android/ios
* using new class RouteNotificationMessages in navigator
* Fixing analyzer issues.
* fixing cycle dependency
* fixing github analyze error
* dartfmt two new classes. trying to fix anayze errors
* Update route_notification_messages.dart
* trying to fix white space errors
This reverts commit 92ef2b9ce1.
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.
