[beta] Cherry pick fix GTK redraw call being called from non-GTK thread#173667
Conversation
gtk_widget_queue_draw is not thread-safe, call it from an idle callback. Fixes flutter#173447
github-actions
bot
added
a: tests
|
This pull request was opened from and to a release candidate branch. This should only be done as part of the official Flutter release process. If you are attempting to make a regular contribution to the Flutter project, please close this PR and follow the instructions at Tree Hygiene for detailed instructions on contributing to Flutter. Reviewers: Use caution before merging pull requests to release branches. Ensure the proper procedure has been followed. |
![gemini-code-assist[bot]](proxy.php?url=https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request is a rollup of several changes, including a fix for a Linux window resize lockup, and a major refactoring of iOS device launching to support LLDB. The changes are generally high quality and well-tested. I have one suggestion to improve the new iOS launch logic by reducing code duplication and using the newly introduced launcher class more consistently.
robert-ancell
changed the title
camsim99
added
the
emergency
|
Detected the If you add the The "Merge" button is also unlocked. To bypass presubmits as well as the tree status, press the GitHub "Add to Merge Queue". |
camsim99
added
autosubmit
|
The tree is green so not sure why tree status is red? Thinking about bypassing and landing this. |
camsim99
added
the
emergency
auto-submit
bot
merged commit afefd5d
into
flutter:flutter-3.35-candidate.0
4 participants
Cherry pick of #173602
Impacted users: All Linux users of Flutter
Impact Description: Due to calling gtk_window_redraw on a Flutter thread a lock up may occur. The Flutter app will then become unresponsive.
Workaround: No workaround
Risk: Low - fix is to run the GTK call on the GTK thread which is what the correct behaviour should be.
Test coverage: Rendering covered by existing tests, use of thread not explicitly tested, but #173660 opened to add this in future.
Validation Steps: Run test program in #173447 which generates many frames and maximizes the chance of a lock up.