Closed NickEntin closed 6 months ago
This problem is actually happening at two separate levels: when we snapshot the view under test and when we snapshot the container view. In some cases, where we're right at the threshold, we may successfully snapshot the view under test but fail to snapshot the container view (since the container view is larger in most cases).
I consider this to be three separate bugs: a bug in our rendering of the view under test, and a bug in each of the snapshotting engines we use for snapshotting the container view. I opened #76 to address the rendering of the view under test. We should probably open issues against iOSSnapshotTestCase and SnapshotTesting to apply similar fixes.
There's sort of a workaround we could apply when using SnapshotTesting - we could always use drawHierarchyInKeyWindow: false
when snapshotting the container view. In theory there shouldn't be any difference since the container view doesn't have a real reason to use that rendering mode (there aren't any 3D transforms, effects views, etc.); however, from testing there are actually some minor rendering differences, which means consumers would need to upload all of their reference images. This isn't ideal, so I think fixing the issue inside SnapshotTesting is preferable.
I'm marking this as blocked
since we've resolved as much of it as we reasonably can within AccessibilitySnapshot for now.
I'm gonna go ahead and mark this as closed since there's no additional changes needed inside AccessibilitySnapshot to support this.
Views that are very large in at least one dimension (reproduced with a view that was 2870 pt tall) will silently fail to render when using the
.drawHierarchyInRect
rendering mode, producing an empty snapshot of the view.cc @efirestone