Repository navigation
Don't send app lifecycle events unless there's a listener #131452
Description
Repro steps
On macOS:
- Using a locally built engine, run the spinning square example or any app that doesn't use the widgets layer
- Hide/show the window a few times
You'll see the following errors in the console:
> flutter run --local-engine host_debug_unopt -d macos ./raw/spinning_square.dart
flutter: A message on the flutter/lifecycle channel was discarded before it could be handled.
This happens when a plugin sends messages to the framework side before the framework has had an opportunity to register a listener. See the ChannelBuffers API documentation for details on how to configure the channel to expect more messages, or to expect messages to get discarded:
https://api.flutter.dev/flutter/dart-ui/ChannelBuffers-class.html
The capacity of the flutter/lifecycle channel is 1 message.
Solution
We shouldn't send flutter/lifecycle messages unless the Dart app has a listener for that channel.
/cc @gspencergoog
Activity
loic-sharma commentedon Aug 11, 2023
@bleroux provided the excellent suggestion that we could set the lifecycle channel's size to
0so that messages are dropped if the framework isn't subscribed. If we go with this approach, we'd likely want to add a "synchronize state" message to the lifecycle channel so that the framework can get its initial state at start up.bleroux commentedon Aug 11, 2023
Great!
For clarification, if the only goal is to remove the error messages, the solution is not to set the buffer size to 0 but to allow the channel to overflow (see https://github.com/flutter/engine/blob/93e8901490e78c7ba7e319cce4470d9c6478c6dc/lib/ui/channel_buffers.dart#L304C1-L309C35).
Setting the buffer size to 0 makes sense if the buffered message could be obsolete when delivered (this is the case in order to fix #125975).
FYI, I’m working on several PRs to add helper functions for the ‘resize’ and ‘overflow’ commands (see #132386).
I filed flutter-team-archive/engine#44636 for Linux and flutter-team-archive/engine#44434 for Android.
I plan to file the macOS implementation at the end of next week. And the Windows one the week after.
gspencergoog commentedon Aug 14, 2023
I've tried manipulating the buffer size before, and when I was initially implementing the lifecycle events I had a little trouble manipulating the buffer size at startup time, simply because the Dart isolate wasn't up and running yet when I needed to set the buffer size. Since the buffer sizing code is in Dart, it doesn't actually change the buffer size in that case.
This might not be an issue here, but I thought I'd mention it.
flutter-triage-bot commentedon Jan 1, 2024
This issue is assigned to @gspencergoog but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!
gspencergoog commentedon Jan 2, 2024
This is still planned work. It seems like setting the buffer size to zero isn't going to work here, for the reasons I outlined above, so we'll need to add a mechanism for telling the engine when listeners have subscribed and unsubscribed. The alternative would be to move the buffering code into each platform implementation so it can take effect even if the Dart isolate isn't running yet, which seems like a lot of duplicated code.
loic-sharma commentedon Feb 27, 2024
FYI, this was fixed on Windows by introducing a "channel updates" embedder API (here, here). The Windows embedder uses this callback to drop lifecycle events (here) until it is notified that the Dart app is listening to the
flutter/lifecyclechannel (here, here)flutter-triage-bot commentedon Jun 7, 2024
The
triaged-desktoplabel is irrelevant if there is noteam-desktoplabel orfyi-desktoplabel.flutter-triage-bot commentedon Oct 11, 2024
This issue is assigned to @gspencergoog but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!