Hi,
Sounds like we’re making some progress. I see some logging in FGenericAccessibleMessageHandler as well, so I’d recommend setting LogAccessibility to Verbose to see if it’s being explicitly deactivated. Since we’re focusing on Windows, it looks like FWindowsUIAManager will deactivate accessibility in FWindowsUIAManager::OnWidgetProviderRemoved, which suggests every FWindowsUIAWidgetProvider was destroyed:
`void FWindowsUIAManager::OnWidgetProviderRemoved(TSharedRef InWidget)
{
CachedWidgetProviders.Remove(InWidget);
if (CachedWidgetProviders.Num() == 0)
{
// If the last widget Provider is being removed, we can disable application accessibility.
// Technically an external application could still be running listening for mouse/keyboard events,
// but in practice I don’t think its realistic to do this while having no references to any Provider.
//
// Note that there could still be control Providers with valid references. In practice I don’t think
// this is possible, but if we run into problems then we can simply call AddRef and Release on the
// underlying widget Provider whenever a control Provider gets added/removed.
OnAccessibilityDisabled();
}
}`Looking back at the callstack, it sounds like that second paragraph is exactly what could be happening here. That could also explain why it’s sporadic, since it would only be a problem if a message came in while there were no accessible widgets and the system has been made inactive. If you want to test out that theory, we could have the control provider increment the RefCount on the widget provider as suggested:
`// FWindowsUIAControlProvider
FWindowsUIAControlProvider::FWindowsUIAControlProvider(FWindowsUIAManager& InManager, TSharedRef InWidget)
: FWindowsUIABaseProvider(InManager, InWidget)
{
UIAManager->GetWidgetProvider(Widget).AddRef();
}
FWindowsUIAControlProvider::~FWindowsUIAControlProvider()
{
UIAManager->GetWidgetProvider(Widget).Release();
}`Best,
Cody