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
[Documentation]: Make Sample code for AbsorbPointer simpler #87936
The following sample has an [AbsorbPointer] widget wrapping the button on top of the stack, which absorbs pointer events, preventing its child button and the button below it in the stack from receiving the pointer events.
But any widget below another widget is already prevented from getting the pointer events. So pointing it out here, asif it is new, seems weird. The example taken in the video would be a better sample - Wrapping a bunch of widgets with AbsorbPointer.
changed the title [-]Sample code for AbsorbPointer seems like overkill[/-][+][Documentation]: Make Sample code for AbsorbPointer simpler[/+]on Aug 9, 2021
Hi :) I'm new to open source and to the flutter community and would love to work on this issue, may I?
Could you give me some pointers on how to continue?
Many thanks!
Go through the CONTRIBUTING and SETUP guide. Next, understand the issue, read the documentation and try to solve it by raising a PR. For any doubts, reach out to the community on the discord server in hackers-new channel. You can also refer this blog for more guidance.
Hi — looks like the 2021 volunteer didn't follow through, so picking this up if it's still open for outside contributions. Reporter's concern is valid: the existing sample uses two buttons in a Stack, but the upper button already absorbs taps via normal hit-test order, so the example doesn't actually demonstrate AbsorbPointer's distinctive behavior.
Proposed scope:
Replace the sample with one that contrasts AbsorbPointer against the no-wrapper case, so the unique effect is observable. Specifically: a single visible, enabled-looking button wrapped in AbsorbPointer(absorbing: true). The button looks tappable but isn't — demonstrating that AbsorbPointer makes a subtree opaque to pointer events without changing its appearance.
Optionally add a short prose note (or second sample) clarifying the AbsorbPointer vs IgnorePointer distinction (absorbed events stop at the AbsorbPointer; ignored events pass through to widgets below in the hit-test stack). The current dartdoc already mentions this once but doesn't show it.
Verify the new dartpad sample renders and passes existing test infrastructure for code samples in the framework docs.
Happy to defer if this is already on someone's plate, or trim/expand if you'd prefer a different specific scenario (e.g. demonstrating the use case during an animation / transition).
The example taken in the video would be a better sample - Wrapping a bunch of widgets with AbsorbPointer.
Hi @werainkhatri, while this example looks good visually, I don't think it allows users to understand the difference between IgnorePointer and AbsorbPointer.
I think a better solution is adding this as a new example, then updating the current example to add a side-by-side comparison with an IgnorePointerExample next to the current AbsorbPointerExample. The example app should encourage the user to click on both, and observe that in the AbsorbPointerExample, clicking on the AbsorbPointer area does not allow hit-tests pass through the widget to the underlying button, while IgnorePointer does.
Hi @victorsanni — I posted a similar proposal a few days ago (just above) and I like your side-by-side approach: keeping the existing example and adding an IgnorePointer example next to it makes the distinction obvious without invalidating the original. Are you planning to implement this yourself, or would you like me to take it on with your suggested design? Happy either way — just want to avoid us both doing the same work.
I'd like to take this. Following @victorsanni suggestion: keep the existing example and add an IgnorePointer counterpart so the side-by-side makes the distinction observable. @victorsanni does that design still look right to you, and would you be able to review when it's up?
Hi @kiddo4 — just flagging that I claimed this one back on May 22 and proposed the same keep-both/side-by-side plan on May 27 following @victorsanni's suggestion (see above). I never heard back on the design question, but since we've all converged on the same approach, I'll have the PR up in the next few days — happy to have more eyes on it once it's open!
As promised, the PR is up: #188940. It keeps the original example and adds the IgnorePointer counterpart side by side, with a visible tap counter under each stack so the difference is actually observable (tapping the overlap does nothing on the AbsorbPointer side, increments the counter behind on the IgnorePointer side), following @victorsanni's design. It's a draft for now only because of the open-PR limit for outside contributors — I'll mark it ready for review as soon as one of my other PRs frees a slot.
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
[-]Sample code for AbsorbPointer seems like overkill[/-][+][Documentation]: Make Sample code for AbsorbPointer simpler[/+]YairShachar commentedon Aug 10, 2021
Hi :) I'm new to open source and to the flutter community and would love to work on this issue, may I?
Could you give me some pointers on how to continue?
Many thanks!
werainkhatri commentedon Aug 10, 2021
Sure.
Go through the CONTRIBUTING and SETUP guide. Next, understand the issue, read the documentation and try to solve it by raising a PR. For any doubts, reach out to the community on the discord server in hackers-new channel. You can also refer this blog for more guidance.
YairShachar commentedon Aug 11, 2021
Great I'm on it. Thanks!
theprantadutta commentedon May 22, 2026
Hi — looks like the 2021 volunteer didn't follow through, so picking this up if it's still open for outside contributions. Reporter's concern is valid: the existing sample uses two buttons in a
Stack, but the upper button already absorbs taps via normal hit-test order, so the example doesn't actually demonstrateAbsorbPointer's distinctive behavior.Proposed scope:
AbsorbPointeragainst the no-wrapper case, so the unique effect is observable. Specifically: a single visible, enabled-looking button wrapped inAbsorbPointer(absorbing: true). The button looks tappable but isn't — demonstrating thatAbsorbPointermakes a subtree opaque to pointer events without changing its appearance.IgnorePointerdistinction (absorbed events stop at theAbsorbPointer; ignored events pass through to widgets below in the hit-test stack). The current dartdoc already mentions this once but doesn't show it.dartpadsample renders and passes existing test infrastructure for code samples in the framework docs.Happy to defer if this is already on someone's plate, or trim/expand if you'd prefer a different specific scenario (e.g. demonstrating the use case during an animation / transition).
victorsanni commentedon May 27, 2026
Hi @werainkhatri, while this example looks good visually, I don't think it allows users to understand the difference between
IgnorePointerandAbsorbPointer.I think a better solution is adding this as a new example, then updating the current example to add a side-by-side comparison with an
IgnorePointerExamplenext to the currentAbsorbPointerExample. The example app should encourage the user to click on both, and observe that in theAbsorbPointerExample, clicking on theAbsorbPointerarea does not allow hit-tests pass through the widget to the underlying button, whileIgnorePointerdoes.theprantadutta commentedon May 27, 2026
Hi @victorsanni — I posted a similar proposal a few days ago (just above) and I like your side-by-side approach: keeping the existing example and adding an
IgnorePointerexample next to it makes the distinction obvious without invalidating the original. Are you planning to implement this yourself, or would you like me to take it on with your suggested design? Happy either way — just want to avoid us both doing the same work.kiddo4 commentedon Jun 25, 2026
I'd like to take this. Following @victorsanni suggestion: keep the existing example and add an IgnorePointer counterpart so the side-by-side makes the distinction observable. @victorsanni does that design still look right to you, and would you be able to review when it's up?
theprantadutta commentedon Jul 3, 2026
Hi @kiddo4 — just flagging that I claimed this one back on May 22 and proposed the same keep-both/side-by-side plan on May 27 following @victorsanni's suggestion (see above). I never heard back on the design question, but since we've all converged on the same approach, I'll have the PR up in the next few days — happy to have more eyes on it once it's open!
theprantadutta commentedon Jul 3, 2026
As promised, the PR is up: #188940. It keeps the original example and adds the
IgnorePointercounterpart side by side, with a visible tap counter under each stack so the difference is actually observable (tapping the overlap does nothing on theAbsorbPointerside, increments the counter behind on theIgnorePointerside), following @victorsanni's design. It's a draft for now only because of the open-PR limit for outside contributors — I'll mark it ready for review as soon as one of my other PRs frees a slot.Make the AbsorbPointer sample show the difference from IgnorePointer (f…
github-actions commentedon Sep 12, 2026
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.