Description

Currently a modal route is dismissed by callback onTap. This has 2 problems:

• It should be dismissed by tap down instead of tap up.
• After Redo#2: Add buttons to gestures #31935, onTap* will only respond to primary buttons, which means secondary (and other) buttons will no longer able to dismiss modals.

To fix this, we need a tap gesture recognizer that responds to any buttons. However, adding onAnyTap* as a public API to TapGR might not be a good idead for 2 reasons:

1. It's the only occasion we've found onAnyTap* needed for now. Might not worth the cost of adding a full set of public API, especially considering...
2. onAnyTap* is easy to misuse (because it competes in all events)

Instead ModalBarrier will use a private recognizer _AnyTapGestureRecognizer that claims victor and calls onAnyTapDown immediately after it receives any PointerDownEvent.

Changes

• Methods tap, press, and related ones in WidgetController support customizing buttons.
• Add private classes _AnyTapGestureRecognizer and _ModalBarrierGestureDetector.
• ModalBarrier uses _ModalBarrierGestureDetector.onAnyTapDown to dismiss.

Related Issues

• None

Tests

I added the following tests:

• ModalBarrier pops the Navigator when dismissed by non-primary buttons

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I signed the CLA.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I updated/added relevant documentation (doc comments with ///).
• All existing and new tests are passing.
• The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require Flutter developers to manually update their apps to accommodate your change?

• Yes, this is a breaking change (Please read Handling breaking changes). Replace this with a link to the e-mail where you asked for input on this proposed change.
• No, this is not a breaking change.