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
Assert if a transparent container absorbs hits #51000
This would be a behavior change, but I think I would find it confusing to have a transparent container absorbe hits. Today, Container(color: Colors.transparent) absorbs hits.
I'm marking this as stretch goals since it's not clear at this point if anyone is actually suffering because of this - if we find out it's causing confusion it shouldn't be too hard to fix though.
Would first do hit testing on the child sized box. If the tap fell outside the sized box but still was inside the container, the container would return true from hitTest.
I think that behavior is probably confusing in a fully-transparent colored container.
Can you explain the usage of this? Because I think it's more like a feature so that there is a way to absorb hits. Additionally we have to make sure all decorations are off to consider the container transparent, including color, image, border, shadow, etc, and not even a color with 1% alpha. On the other hand, you can always put the container inside the size box, isn't it?
We talked offline - my take at this point is that if we do anything about this, it's just add an assert. If a Container (or ColoredBox, or Decoration) gets a hitTestSelf request and its color is fully transparent, something is probably wrong - there's an invisible widget that is not an AbsorbePointer absorbing hits, and it's probably more expensive than just having an absorb pointer.
changed the title [-]Consider making a transparent container/coloredbox/boxdecoration not participate in hit testing[/-][+]Assert if a transparent container absorbs hits[/+]on Mar 9, 2020
Activity
dnfield commentedon Feb 19, 2020
That would be a major break. If that were to happen, this issue would be unnecessary.
If we decide to do that, it should be not be to resolve this issue.
dkwingsmt commentedon Feb 19, 2020
(Sorry for deleting my last reply, since I think I misunderstood the request.)
Do you mean that this transparent container should not even prevent sibling objects behind it from being hit?
dnfield commentedon Feb 19, 2020
Today, this widget:
Would first do hit testing on the child sized box. If the tap fell outside the sized box but still was inside the container, the container would return true from
hitTest.I think that behavior is probably confusing in a fully-transparent colored container.
dkwingsmt commentedon Feb 19, 2020
Can you explain the usage of this? Because I think it's more like a feature so that there is a way to absorb hits. Additionally we have to make sure all decorations are off to consider the container transparent, including color, image, border, shadow, etc, and not even a color with 1% alpha. On the other hand, you can always put the container inside the size box, isn't it?
dnfield commentedon Feb 19, 2020
We talked offline - my take at this point is that if we do anything about this, it's just add an assert. If a Container (or ColoredBox, or Decoration) gets a hitTestSelf request and its color is fully transparent, something is probably wrong - there's an invisible widget that is not an AbsorbePointer absorbing hits, and it's probably more expensive than just having an absorb pointer.
[-]Consider making a transparent container/coloredbox/boxdecoration not participate in hit testing[/-][+]Assert if a transparent container absorbs hits[/+]