You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Desktop embedding mouse clicks do not register #31884
cc @dkwingsmt, lets sit down tomorrow and get the desktop targets setup locally so we can figure out if this is something that needs to change in the embedder, the framework, or both
As a starting point, it doesn't look like FlutterEngineSendPointerEvent is setting any button data. Until the API includes button information (which we should add soon), that method should probably hard-code a primary button.
I tested a quick hack of hard-coding buttons to 1 for down, move, and up events in FlutterEngineSendPointerEvent and that fixed it, so that is indeed the problem.
The right fix is two-stage:
Do the above, but cleaned up (e.g., we need to actually provide constants for the embedder to use for primary button, secondary button, etc. that match the Dart values, which I didn't see in a quick glance around). We also need to validate that that's the right set of change types to apply it to (e.g., I guessed up should have the button that was released set, but I didn't check what Flutter is expecting so that may not be right.)
Add a button field to the embedding API (and expose constants for buttons there), and make 1) conditional on the struct provided not being large enough to include the new field, so that clients can be updated to send the actual buttons, but existing clients won't be broken.
Just doing 1) is enough to unblock re-landing, but we should do 2) shortly after.
@chinmaygarde since it will touch the embedding API, so he'll probably want to be aware of this.
I can take care of 2) in the next few days if nobody else has cycles; I may or may not have time for 1) today though. Let's discuss offline.
I think we should fix it as I described above though, not by adding synthesis logic in converter.dart, since that's consistent with the general goal of putting platform-specific (in this case, the embedding API is itself a platform that we have some control over) input handling in the platform, rather than handling variations at the level of the Dart framework code.
Edit: To be clear:
is the desktop embedder sending
It's not "the desktop embedder" thats' doing this, it's all embedders, because the embedding API itself sets those values. They aren't yet exposed at the embedding API layer (thus step 2 in my comment.)
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
stuartmorgan-g commentedon May 1, 2019
If this can't be fixed today, we should revert, since this cripples desktop.
stuartmorgan-g commentedon May 1, 2019
As a starting point, it doesn't look like
FlutterEngineSendPointerEventis setting any button data. Until the API includes button information (which we should add soon), that method should probably hard-code a primary button.stuartmorgan-g commentedon May 1, 2019
I tested a quick hack of hard-coding
buttonsto 1 fordown,move, andupevents inFlutterEngineSendPointerEventand that fixed it, so that is indeed the problem.The right fix is two-stage:
upshould have the button that was released set, but I didn't check what Flutter is expecting so that may not be right.)Just doing 1) is enough to unblock re-landing, but we should do 2) shortly after.
@chinmaygarde since it will touch the embedding API, so he'll probably want to be aware of this.
I can take care of 2) in the next few days if nobody else has cycles; I may or may not have time for 1) today though. Let's discuss offline.
dkwingsmt commentedon May 1, 2019
@stuartmorgan @jonahwilliams Ohhhhh, is the desktop embedder sending
kind = PointerDeviceKind.mouseas well asbuttons = 0? I assumed mouse events needed no synthesizing, it seems it should https://github.com/flutter/flutter/pull/31819/files#diff-c1dfac99ccc50aaadb3a3d5fbd299908R50 😞stuartmorgan-g commentedon May 1, 2019
Correct, see https://github.com/flutter/engine/blob/master/shell/platform/embedder/embedder.cc#L727
I think we should fix it as I described above though, not by adding synthesis logic in converter.dart, since that's consistent with the general goal of putting platform-specific (in this case, the embedding API is itself a platform that we have some control over) input handling in the platform, rather than handling variations at the level of the Dart framework code.
Edit: To be clear:
It's not "the desktop embedder" thats' doing this, it's all embedders, because the embedding API itself sets those values. They aren't yet exposed at the embedding API layer (thus step 2 in my comment.)
github-actions commentedon Aug 29, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.