Exclude Tooltip's overlay child from SelectableRegion

[LongCatIsLooong]

Fixes #129969 by making tooltip text unselectable (for now).
Also fixes some other issues uncovered when I was writing the tests.

Currently getTransformTo only works on ancestors. I'll try to add a new method that computes the transform from 2 arbitrary render objects in the same render tree in a follow-up PR and make Selectable use that method instead.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[chunhtai]

This is surprising, why would it still fire if _longPressRecognizer is disposed?

[LongCatIsLooong]

onCancel is called when an OneSequenceGestureRecognizer disposes:

stack trace:

#9      TooltipState._handleTapToDismiss (package:flutter/src/material/tooltip.dart:564:5)
#10     GestureRecognizer.invokeCallback (package:flutter/src/gestures/recognizer.dart:275:24)
#11     LongPressGestureRecognizer._checkLongPressCancel (package:flutter/src/gestures/long_press.dart:687:13)
#12     LongPressGestureRecognizer.resolve (package:flutter/src/gestures/long_press.dart:822:9)
#13     OneSequenceGestureRecognizer.dispose (package:flutter/src/gestures/recognizer.dart:393:5)
#14     PrimaryPointerGestureRecognizer.dispose (package:flutter/src/gestures/recognizer.dart:689:11)

[chunhtai]

This seems weird to me, the on cancel usually used for cleaning up the state in the owner when gesture is in progress. The owner won't expect the on cancel to be called if it is actively disposing the recognizer. it would be the owner's responsibility to clean up and state left behind when disposing the resource. WDYT?

[LongCatIsLooong]

From the gesture recognizer's perspective I guess that's expected? When there's an onGestureStart someone would expect either an onGestureUp or onGestureCancel. The owner of the gesture recognizer may not be the owner of the gesture callbacks ?

e.g. SomeWidgetWhoseElementOwnsALongPressGestureRecognizer(this.onLongPress, this.onLongPressCancel), when this widget unmounts the parent widget may appreciate that they're getting an onLongPressCancel to pair up with the onLongPress they received previously?

[chunhtai]

I think the correct way would probably be SomeWidgetWhoseElementOwnsALongPressGestureRecognizer would have to call the cancel or up callback on dispose instead of directly hook up to the recognizer and expect it to call the cancel on dispose, but I can see this design can be hard to maintain.

Can the TooltipState be smart to ignore on cancel when the state itself is disposed? if not, i am ok with the code as-is. We should document the reason here more specific why we need to remove the cancel. ie.
Disposing the recognizer can fire oncancell if gesture is in progress.

[chunhtai]

LGTM.

[chunhtai]

I think the correct way would probably be SomeWidgetWhoseElementOwnsALongPressGestureRecognizer would have to call the cancel or up callback on dispose instead of directly hook up to the recognizer and expect it to call the cancel on dispose, but I can see this design can be hard to maintain.

Can the TooltipState be smart to ignore on cancel when the state itself is disposed? if not, i am ok with the code as-is. We should document the reason here more specific why we need to remove the cancel. ie.
Disposing the recognizer can fire oncancell if gesture is in progress.