Skip to content

[Documentation]: Make Sample code for AbsorbPointer simpler #87936

Closed

Description

@werainkhatri

The sample code in AbsorbPointer states that:

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.

Activity

  1. added
    in triagePresently being triaged by the triage team
    d: api docsIssues with https://api.flutter.dev/
    a: qualityA truly polished experience
    and removed
    in triagePresently being triaged by the triage team
    on Aug 9, 2021
  2. changed the title [-]Sample code for AbsorbPointer seems like overkill[/-] [+][Documentation]: Make Sample code for AbsorbPointer simpler[/+] on Aug 9, 2021
  3. YairShachar commented on Aug 10, 2021

    @YairShachar

    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!

  4. werainkhatri commented on Aug 10, 2021

    @werainkhatri
    MemberAuthor

    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.

  5. YairShachar commented on Aug 11, 2021

    @YairShachar

    Great I'm on it. Thanks!

  6. added
    frameworkflutter/packages/flutter repository. See also f: labels.
    on Aug 17, 2021
  7. added
    P2Important issues not at the top of the work list
    on Apr 6, 2022
  8. self-assigned this
    on Mar 1, 2026
  9. removed their assignment
    on May 1, 2026
  10. theprantadutta commented on May 22, 2026

    @theprantadutta
    Contributor

    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:

    1. 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.
    2. 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.
    3. 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).

  11. victorsanni commented on May 27, 2026

    @victorsanni
    Contributor

    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.

  12. theprantadutta commented on May 27, 2026

    @theprantadutta
    Contributor

    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.

  13. kiddo4 commented on Jun 25, 2026

    @kiddo4

    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?

  14. theprantadutta commented on Jul 3, 2026

    @theprantadutta
    Contributor

    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!

  15. theprantadutta commented on Jul 3, 2026

    @theprantadutta
    Contributor

    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.

  16. github-actions commented on Sep 12, 2026

    @github-actions

    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.

  17. locked as resolved and limited conversation to collaborators on Sep 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Important issues not at the top of the work lista: qualityA truly polished experienced: api docsIssues with https://api.flutter.dev/frameworkflutter/packages/flutter repository. See also f: labels.team-frameworkOwned by Framework teamtriaged-frameworkTriaged by Framework team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions