Fix crash from alt-tab'ing just after startup #102453
Conversation
There is a common failure on desktop platforms that I and other
developers have experienced. If you do the following sequence of
actions, your app will start logging endless "assertion failed" messages
and stop responding to mouse events:
- start the app with 'flutter run'
- position your mouse above where the app window will load
- when the app loads, alt-tab away from it, then alt-tab back
This is a sequence I have done unintentionally many times, and --
judging by these isse reports -- so have others:
- Fixes #76325
- Fixes #80867
- Fixes #90838
- Fixes #98262
- Fixes #99761
- Fixes #100659
- #70375 (comment)
- Possibly #70375 ?
- Possibly #93233 ?
- Possibly #96364 ?
It looks like the problem is that when you do that series of actions,
the first mouse event that the app sees is a Removed event. The
author(s) of mouse_tracker.dart assumed that such a thing could not
happen, and even (helpfully) put in an assertion to that effect.
I don't have a deep understanding of the mouse tracker, but it appears
that a reasonable response to receiving an initial Removed event is to
simply ignore the event and wait for the next one. Doing this fixes the
crash, and the mouse continues to work afterward.
flutter-dashboard
bot
added
the
framework
dkwingsmt
left a comment
dkwingsmt
left a comment
There was a problem hiding this comment.
LGTM. Thanks for the investigation!
Co-authored-by: Tong Mu <[email protected]>
|
I'm requesting a second review. |
|
This appears to have broken the build: Not sure how this wasn't caught by the pre-commit checks. Unless there is a quick fix for this, I will revert this shortly to get the tree green again. |
This reverts commit 74e9a6d.
|
I looked into at why this assertion was happening in Linux desktop apps (see #100659) There is a race between Linux embedder startup and framework startup which can cause the first pointer add event to be sent by the One option would be fixing this by buffering the pointer events in the engine. But it's probably simpler to relax the requirements for the embedder's event stream and just ignore the mismatched event as is done in this PR. |
|
I was suspecting the same. Keyboard events used to face the same problem and we switched to the messenger, which supports message buffering flutter/engine#29795. However this is not enough. The message buffering only supports one message, and at least for keyboard it's not hard to build a scenario that overflows (see #89748). We can resize the buffer, but to how much? Any size is an arbitrary size. So I think the ultimate goal is for the framework to initiate a "startup request" and the engine replies with an initial state. Despite this, I still approved this PR since we'd like a more immediate fix. |
|
I have described this issue at #103094. |
…" (flutter#103074) This reverts commit 74e9a6d.
6 participants
There is a common failure on desktop platforms that I and other developers have experienced. If you do the following sequence of actions, your app will start logging endless "assertion failed" messages and stop responding to mouse events:
This is a sequence I have done unintentionally many times, and -- judging by these issue reports -- so have others:
It looks like the problem is that when you do that series of actions, the first mouse event that the app sees is a Removed event. The author(s) of mouse_tracker.dart assumed that such a thing could not happen, and even (helpfully) put in an assertion to that effect.
I don't have a deep understanding of the mouse tracker, but it appears that a reasonable response to receiving an initial Removed event is to simply ignore the event and wait for the next one. Doing this fixes the
crash, and the mouse continues to work afterward.
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.