Hi, we’re running into an issue preventing us from enabling slate global invalidation in 5.5.4 (we previously had success with it on before we upgraded on 5.4.2).
It seems that if a widget (in a retainer) that contains a button/other input blocker is collapsed, the hittest grid will not be updated and anything behind the collapsed widget remains blocked. We reproduced it in a stock 5.5.4 project (attached) as well as our primary project with CL 40790289 already cherrypicked.
Is there a fix for this in main yet? If not, do you have any idea how we might resolve this so we can re-enable global invalidation? Thanks.
Steps to Reproduce
(See repro project)
Widget structure:
- Retainer box
- Modal widget to collapse
- Clickable button
- Something blocked behind the clickable button
Then make sure slate.enableglobalinvalidation = true and build/cook/run
Hi,
I’d expect 40790289 to fix this, as I was unable to reproduce this in main until I commented out the call to HittestGrid->Clear from that change. Do you see SRetainerWidget::PaintSlowPath being called when the modal (or input blocker) is dismissed? Is there anything complex about the setup in your primary project that could be relevant? (i.e. nested retainers)
I don’t see any other changes that seem like they could be relevant here, though it would be interesting to verify if your repro project demonstrates the issue in your custom engine build.
Best,
Cody
Hi,
If you’re able to get a minimal repro then that would definitely be a huge help. Where is the retainer widget in that hierarchy? Is it part of one of the sibling SObjectWidget trees, or wrapping the whole viewport? I’d expect to see it somewhere in the reflector hierarchy there.
Best,
Cody
Ah, it looks like we ran into a similar issue internally and it did indeed to be separate from the issue fixed in that CL. We don’t have a resolution yet, but we’re seeing it when an SObjectWidget is collapsed via a WidgetSwitcher. Our current workaround is to force an invalidation pass by adding/removing the button from the hierarchy (rather than adjust it’s visibility), would that be doable until we have a proper fix?
Best,
Cody
Hi,
Seems reasonable, I’ve made a note to reach out once we have a proper fix. I’ll let you know so that you can reenable global invalidation.
Best,
Cody
Hmm, yeah we definitely have that CL integrated. Here’s a look at the widget reflector hierarchy for one of the widgets that easily reproduces the issue in our main project:
[Image Removed]I’m not sure what there would cause this to behave differently than the case that 40790289 addresses, it’s not very complex.
I’ll see if I can reproduce it in a new project with our engine version.
Seems that my original repro project may have only reproduced the issue that was fixed in CL 40790289 because you’re right, we apparently do not have a retainer widget in the hierarchy. We used to have everything wrapped in a retainer and I mistakenly assumed it was still there, but apparently that is no longer the case according to my screenshot.
That said, I don’t think we have a widget switcher either, so I’m not sure that’s the same issue we’re seeing? Regardless, I can certainly try removing/adding the widget to see if that makes a difference here too, though I fear there are other places in our project that are affected in a similar manner as well.
I suspect it’s still related, as the underlying mechanism of collapsing an SObjectWidget was determined to be the source of the problem. I can’t share the ticket to the public tracker since it has some Fortnite-specific repro info that wouldn’t be too helpful anyway, but I’ll keep an eye on it and reach out when we have a fix so that you can see if it solves your case as well.
Makes sense, thanks. I’ll update you with the results once I have them.
I was able to confirm that removing the widget does update the hittest grid as expected. I also ended up trying FSlateApplication::Get().InvalidateAllWidgets(false); when we collapsed it which also worked.
That said, I discussed with our UI dev and we don’t think it’s realistic for us to track down and manually apply one of these fixes for every instance of these issues in our project in order to re-enable global invalidation. Given that we have already shipped several patches with it disabled, we can likely continue to live with global invalidation disabled until there’s a real engine level fix.