* Added a composable waitForCondition Driver/extension API.
This reverts commit df2db4e50f.
* Added SerializableWaitCondition for communicating between driver script on host and extension on device.
This relands https://github.com/flutter/flutter/pull/35297
The followings have been done to fix the broken tests:
1. Add `didSendFirstFrameRasterizedEvent` extension and its tests
2. Wait for `didSendFirstFrameRasterizedEvent` instead of
`didSendFirstFrameEvent` during start up tests
3. Mark missed (probably newly added) start up tests as flaky
Fixes https://github.com/flutter/flutter/issues/36091.
Previously, a sendRequest will be sent even if the peer is closed during
a driver test. That will cause a time out without any error information.
Such issue is unreproducible on my Mac Book Pro, but 100% reproducible
on our new Mac mini (2018).
The closing issue is tracked in https://github.com/flutter/flutter/issues/36268
Additional to this fix, we should also patch the jason_rpc_2 so the peer
will throw exception if sendRequest is attempted while the connection is
closed.
**Test**:
tiles_scroll_perf_iphonexs__timeline_summary failed without this patch.
It will pass after this patch.
I'm not sure how to add a unit test for this. Please let me know if you have
some ideas.
This patch will generate the following warning log on the new Mac Mini
```
flutter: Observatory listening on http://127.0.0.1:50192/cZPDF4sW7MM=/
Installing and launching... 10.2s
00:00 +0: scrolling performance test (setUpAll)
[info ] FlutterDriver: Connecting to Flutter application at http://127.0.0.1:1069/cZPDF4sW7MM=/
[trace] FlutterDriver: Isolate found with number: 3684677742843303
[trace] FlutterDriver: Isolate is paused at start.
[trace] FlutterDriver: Attempting to resume isolate
[trace] FlutterDriver: Waiting for service extension
[info ] FlutterDriver: Connected to Flutter application.
00:00 +0: scrolling performance test complex_layout_scroll_perf
[warning] FlutterDriver: Instance of '_WebSocketImpl' is closed with an unexpected code 1005
[warning] FlutterDriver: Peer connection is closed! Trying to restore the connection...
00:10 +1: scrolling performance test tiles_scroll_perf
[warning] FlutterDriver: Instance of '_WebSocketImpl' is closed with an unexpected code 1005
[warning] FlutterDriver: Peer connection is closed! Trying to restore the connection...
00:20 +2: scrolling performance test (tearDownAll)
00:20 +2: All tests passed!
Stopping application instance.
```
## Description
Print actionable warnings if `flutter drive` (where most of our performance benchmarks come from) is run in debug mode and it tries to gather benchmarks using `traceAction`.
## Related Issues
https://github.com/flutter/flutter/issues/30625
## Tests
I added the following tests:
* drive_perf_debug_warning devicelab test
* add trailing commas on list/map/parameters
* add trailing commas on Invocation with nb of arg>1
* add commas for widget containing widgets
* add trailing commas if instantiation contains trailing comma
* revert bad change
For `fuchsia_compat.dart` Instead of using `runSync`, use `run` to avoid
deadlock when attempting to access specific resources like the Hub in Fuchsia.
The specific example is that in Fuchsia, the `find` command is
attempting to explore `out` which hasn't yet been serviced, as `find` is
blocking on it, causing a deadlock.
These are essentially self-inflicted race conditions. Instead of timeouts we're going to try a more verbose logging mechanism that points out when things are taking a long time.
When setting the Fuchsia logging function, it should happen before any
initialization code, as init can still cause warning/error/info messages
to get printed to logs. Since the default stderr/stdout fd's aren't
correct, this can cause a program to crash for unclear reasons.
* Remove many timeouts.
These are essentially self-inflicted race conditions. Instead of timeouts we're going to try a more verbose logging mechanism that points out when things are taking a long time.
* Get the attach tests to pass.
* Apply review comments from Todd
* More review comment fixes
* Put back the extended timeouts here now that I know why we have them...
