Assertion failure when a PopupMenu quits after DialogWindow creation



This might be a bug or is just my bad but it’s a bizarre phenomenon anyways. I have a PopupMenu launched in modal state with a menu item inside that launches a DialogWindow by

DialogWindow::LaunchOptions dw;
dw.escapeKeyTriggersCloseButton = true;
dw.useNativeTitleBar = true;
dw.dialogTitle = TRANS("Editor");
dw.content.set(& editorComponent, false);
editorWindow = dw.create();
editorWindow -> setContentComponentSize(640, 400);
editorWindow -> setVisible(true);
editorWindow -> setAlwaysOnTop(true);

The triggering of menu item is implemented using ApplicationCommandManager.
When running the application in debug mode there’s a roughly 1/5 chance of getting stuck at an assertion in Component::grabKeyboardFocus()

void Component::grabKeyboardFocus()
    // if component methods are being called from threads other than the message
    // thread, you'll need to use a MessageManagerLock object to make sure it's thread-safe.

    grabFocusInternal (focusChangedDirectly, true);

    // A component can only be focused when it's actually on the screen!
    // If this fails then you're probably trying to grab the focus before you've
    // added the component to a parent or made it visible. Or maybe one of its parent
    // components isn't yet visible.
    jassert (isShowing() || isOnDesktop());

and this happens before PopupMenu::showAt returns. Note that what’s really strange is that Component::grabKeyboardFocus in this case was called from the destructor of FocusRestorer (juce_Component.cpp:146), which actually checks if the component isShowing thanks to a previous bug fix that prevents getting stuck in this particular assertion. So the return from isShowing() must have been modified by another thread between the initial check and the assertion. The PopupMenu::showAt call happens in the GUI thread though - just to clarify that I’m not doing anything fishy. But isn’t the lock supposed to prevent such a conflict from happening?
I’m pretty lost here. For now, switching to PopupMenu::showMenuAsync seems to be good. I’d still like to know what caused this problem in synchronous call though.