Skip to content

FocusTrap behavior by platform - #99849

Closed
justinmc wants to merge 3 commits into
flutter:masterfrom
justinmc:focus-trap-web
Closed

justinmc wants to merge 3 commits into
flutter:masterfrom
justinmc:focus-trap-web

Conversation

@justinmc

@justinmc justinmc commented Mar 9, 2022

Copy link
Copy Markdown
Contributor

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.

@justinmc justinmc self-assigned this Mar 9, 2022
@flutter-dashboard flutter-dashboard Bot added a: text input Entering text in a text field or keyboard related problems p: material_ui material_ui package in flutter/packages f: routes Navigator, Router, and related APIs. framework flutter/packages/flutter repository. See also f: labels. labels Mar 9, 2022

@jonahwilliams jonahwilliams left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

assert(debugHandleEvent(event, entry));
if (event is! PointerDownEvent
|| event.buttons != kPrimaryButton
|| event.kind != PointerDeviceKind.mouse

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is causing failures because it seems to intercept drag events. I'm checking if this is still viable.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@venkatd

venkatd commented Mar 10, 2022 •

Copy link
Copy Markdown

@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:

  • For autocomplete fields, we don't want to drop focus if you click on an item
  • Tooltips with clickable links should not drop focus
  • In some cases, we want clicking outside to restore focus to the previously focused item (don't want where to restore focus to be hardcoded)

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.

@justinmc

Copy link
Copy Markdown
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

a: text input Entering text in a text field or keyboard related problems f: routes Navigator, Router, and related APIs. framework flutter/packages/flutter repository. See also f: labels. p: material_ui material_ui package in flutter/packages

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants