Hi,
We are working on this issue internally, the hotfix we had fixed an issue internally that we believed to be related to this issue. Besides the other workarounds of disabling global invalidation and manually managing the offending widgets, is it feasible for your team to sync the visibility state of the offending widgets with the authoritative ancestor widget
The change in 5.6.1 will rebuild the hittest grid when the hierarchy is invalidated. When any child widgets under the hierarchy are invalidated, this should trigger a PaintSlowPath, which renders the widget state and rebuilds the hittest grid. In this case, because the Button is marked as Visible, this may still be added to the hittestgrid, regardless of the visibility state.
For instance, when the outer SObjectWidget is collapsed, set the SObjectWidget(ContinueButtonX) to Collapsed or Hidden, and vice versa?
Otherwise, I could propose a few engine modifications that may also be some breadcrumbs
Option 1 - Manully remove the hittest if not retained or visible
int32 SRetainerWidget::OnPaint(...)
{
if (bShouldRetainRendering && IsAnythingVisibleToRender())
{
...
}
else
{
Args.GetHittestGrid().RemoveGrid(HittestGrid); // Add this call
return SCompoundWidget::OnPaint(Args, AllottedGeometry, MyCullingRect, OutDrawElements, LayerId, InWidgetStyle, bParentEnabled);
}
}
Option 2 - In the paint slow path, prevent the render call is
int32 SRetainerWidget::PaintSlowPath(const FSlateInvalidationContext& Context)
{
HittestGrid->Clear();
// Prevent widgets from appending to hittest grid during paint pass
if (IsAnythingVisibleToRender())
{
return;
}
...
}
Yes, apologies missing an `!` in the `IsAnythingVisibleToRender()` call.
Thank you for the additional information.
Hmm, if the hittest grid is still in a bad state, perhaps it is still referenced in an outer hittest grid.
Last quick change I can think of is to explicitly clear the hittest grid before removing.
Also, these changes assume collapsing the outer SObjectWidget changes the visibility of the RetainerWidget. From the hierarchy, I am not sure where the retainerwidget resides relative to the others.
int32 SRetainerWidget::OnPaint(...)
{
if (bShouldRetainRendering && IsAnythingVisibleToRender())
{
...
}
else
{
HittestGrid->Clear();
Args.GetHittestGrid().RemoveGrid(HittestGrid);
return SCompoundWidget::OnPaint(Args, AllottedGeometry, MyCullingRect, OutDrawElements, LayerId, InWidgetStyle, bParentEnabled);
}
}
If this does not work, unfortunately, until our team can work on fixing this, I am not aware of any current solutions besides band-aid fixes, disabling invalidation, etc…
If any additional progress on this issue is made, we will reach out.
I see now. I misunderstood, thank you.
I could not find any existing internally reported issues with SRichTextBlock.
Is your team having issues any other than the SRichTextBlock and SRetainerWidget? Internally we have a ticket to resolve SRetainerWidget, we can create a seperate ticket to resolve the issue with SRichTextBlock.
It’s certainly possible we could set ContinueButtonX to collapsed, but given that this only addresses this one particular widget (and the issue appears systemic, albeit limited in scope), I’d prefer to not keep applying band-aid fixes to an unknown number of other affected widgets that may present themselves if there are more in our project (or future projects).
I attempted both proposed engine modifications (though I assume Option 2 should have been negated in the if statement) since they both seem reasonable, but neither seem to actually fix the problem here (the hit test grid remains in the incorrect state). Based on the findings of my previous reply, perhaps the invalidation list (potentially) getting corrupted is preventing them from having their intended effect?
Ah, we eliminated a retainer widget as a requirement higher up in this thread, this issue actually does not require one to reproduce unlike the other issue you referenced. Sorry I wasn’t clear about that, this thread has gotten a bit convoluted to follow.
So far, based on those validation errors I posted in response to Cody’s suggestion, it seems like something around the SRichTextBlock behaving poorly with global invalidation enabled in general is potentially the issue at play here?
This is the only case that we know consistently reproduces the issue, but we haven’t eliminated the possibility of there being other cases. If there’s something else we can try to gather more information, let me know and I can take a look.