Repository navigation
TabBar does not allow detection of taps #24224
Description
Problem
We have come up against a wall in our project because of this a couple times now. The latest example is as follows:
We have a TabBar with two Tabs, both of which contain lists. If we are in Tab X, and the user taps on the header for Tab X, we want to scroll the list up to the top. If the user taps Tab Y, we of course want to animate there. This currently seems to be impossible. We can wrap a GestureDetector around a Tab child of TabBar and sort of intercept taps, but this only works for the actual icon and text of the Tab, not the padding around it. Moreover, it disables the normal reaction to taps on the icon and text (tabs no longer switch when tapping there).
Another example would be bookkeeping of the current tab index. The TabController does allow for access to the index, and we can be notified by subscribing to the TabController, but it cannot be trusted because of the following behaviour:
When tapping on a tab:
- Notified
- Widget is built
- Notified
When swiping to a tab:
- Widget is built
- Notified
This means that it is impossible to react to swipes and we always need to be aware of the fact that we might currently be in a swipe, but the system is simply not telling us. As a result, we cannot keep track of
the current index of tabs, since it can be corrupted by a simple swipe (and any workarounds are unnecessarily complicated).
Finally, while this is not something we need, it is also currrently impossible to disable tapping on the TabBar, see this SO question.
Fix
See PR #23919
Activity
Hixie commentedon Nov 14, 2018
cc @HansMuller @goderbauer
Hixie commentedon Nov 20, 2018
Disabling tabs entirely is possible with
IgnorePointer.So is the request here merely to be told when the user taps on a Tab that is already showing?
JaspervanRiet commentedon Nov 20, 2018
Wasn't aware of that. Our specific request is to be told when a user taps on a tab, and be given the index of the tab, so that we can take action based on this tap.
Hixie commentedon Nov 20, 2018
Would it be sufficient to take the approach in #23919 but always call _handleTap regardless, instead of having the onTap handler override it?
JaspervanRiet commentedon Nov 20, 2018
Yes, that would be the suggestion I provided in #23919 which would work for us just fine (and is what we've actually implemented locally to give us this functionality). Could basically take my pull request and make that slight change to it and it would work.
JaspervanRiet commentedon Nov 28, 2018
@Hixie #23919 now incorporates your suggestion.
JaspervanRiet commentedon Dec 12, 2018
This issue is actually fixed once #23919 is merged. #24892 actually fixes #24424
HansMuller commentedon Dec 12, 2018
Sorry, bad bookeeping. I just merged #23919 and will try and land it today.
github-actions commentedon Aug 14, 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.