Why are we forcing this to null now instead of keeping the original event if available?

Short version: In order to prevent the type system complaining, either we set this to null, which satisfies the current definition of original, or we change the type of original in the constructor, which also changes the definition of original.

Long version: An error will be thrown in this as-cast when converting other event types using fromMouseEvent (e.g. from PointerDownEvent to PointerEnterEvent). This as-cast was not here when this constructor was first created, but is reasonable since the constructor requires original to be PointerEnterEvent, which also makes sense since original was added for the transformed constructor to transform between coordinate space. So if we think it this way, this original should be null because original was not defined to suit in the type converting case.

Why are we switching this around? Even when it is disabled it should still respond to hovers?

Yes. A widget should never turn off the mouse region when it's disabled.

The mouse cursor algorithm detects the first MouseTrackerAnnotation found and uses its cursor. If the MouseRegion is hidden behind the IgnorePointer then the widget will never be able to show its disabled cursor, and the cursor will incorrectly be the one of the widget behind it, as if the TextField does not exist. A test that is violated can be found at

The reason why this isn't found earlier is probably because IgnorePointer and AbsorbPointer failed to support mouse events (incorrectly, see #35213).

Why do we still need to have a separate hit testing pass for mouse events? Can that not be integrated with the regular hit testing now as well?

Without mouse,

• During hover events, no regular hit test is done.
• During down events, a regular hit test is done, so this is an extra pass, but down events happen at such a low frequency that we might not really care.
• During move events, no regular hit test is done (the result of down events is reused).

Conclusion: The only "extra pass" is the ones at down events, which do not really matter.

I am more concerned about the extra code complexity that we have to deal with because the paths are not unified.

If the mouse device update is triggered by a pointer event, then the code path is indeed more complicated than necessary:

GestureBinding.dispatchEvent -> PointerRouter.route -> MouseTracker._handleEvent -> hit test

Maybe we could've done the hit test at GestureBinding.dispatchEvent and pass it all the way to MouseTracker._handleEvent.

But the mouse device update can also be triggered after every frame, during the post-frame callbacks:

SchedulerBinding.handleDrawFrame -> MouseTracker._updateAllDevices -> hit test

In this case MouseTracker have to initiate a hit test for each device, without the participation of GestureBinding at all.

I'm not saying that a much more unified structure can not be achieved at all, but for now I'd rather touch as few things as possible in order to see the performance impact of the current PR.

This assert is a little odd. Why do we assert after removing that there's still something in _transforms? Shouldn't we assert before?

The _transforms should never be empty, because there should at least be the pre-seeded identity matrix.

Of course it shouldn't be empty before the operation either, but that would be detected by removeLast anyway.

I am more concerned about the extra code complexity that we have to deal with because the paths are not unified.