Repository navigation
Conversation
| assert(debugHandleEvent(event, entry)); | ||
| if (event is! PointerDownEvent | ||
| || event.buttons != kPrimaryButton | ||
| || event.kind != PointerDeviceKind.mouse |
There was a problem hiding this comment.
This is causing failures because it seems to intercept drag events. I'm checking if this is still viable.
There was a problem hiding this comment.
This will now compete with scrolling drags - which will push gesture acceptance out. Actually reading this PR, I'm not sure that changing this condition is a good idea.
|
@justinmc is it possible to make this behavior possible opt out? Flutter web is our primary target, but we don't always want to cause clicking outside to lose focus. So we've had to hack around the FocusTrap behavior. Some examples:
This may also interfere with super_editor when it implements an anchor system https://github.com/superlistapp/super_editor/issues/424 showing toolbars for a selection I propose using the following rule-of-thumb: if a behavior is platform-specific, it should be opt-out and not hardcoded inside the framework. |
|
Looks like this is running into the same kinds of gesture arena problems that #86972 is. I'm going to close this in favor of hoping for a full solution like that to be able to resolve the gesture problems. |
Based on my testing of native platforms, only web (mobile and desktop) remove focus when tapping on an empty area. All other platforms do not. This PR makes Flutter match that behavior.
Related to #92541 and #92079
A full solution for FocusTrap behavior would be #86972.