The observed issue here was that, prior to this change, this type of FAB view hierarchy would result in an incorrect layout capture for anchored tooltips, for the tagged "view-tag" element - putting the FAB element at origin (0,0) in the top left of the view, rather than actual position.
interestingly, it appeared that a much simpler structure with no wrapping elements, and Semantics applied directly to the child label, like below, could work in some scenarios:
further debugging showed that the view coordinate transformation logic was hitting issues with some of the parent views matrix transforms, and the underlying reason is not totally clear still. By adding the changes in this PR, it allows a failed translation to fall back to transforming the top-left origin of the view rect and still being able to translate it into the parent coordinate system.
Also referenced the Flutter source here for some guidance and ideas.
The observed issue here was that, prior to this change, this type of FAB view hierarchy would result in an incorrect layout capture for anchored tooltips, for the tagged
"view-tag"
element - putting the FAB element at origin (0,0) in the top left of the view, rather than actual position.interestingly, it appeared that a much simpler structure with no wrapping elements, and Semantics applied directly to the child label, like below, could work in some scenarios:
further debugging showed that the view coordinate transformation logic was hitting issues with some of the parent views matrix transforms, and the underlying reason is not totally clear still. By adding the changes in this PR, it allows a failed translation to fall back to transforming the top-left origin of the view rect and still being able to translate it into the parent coordinate system.
Also referenced the Flutter source here for some guidance and ideas.