Bug? Context menus flash momentarily and disappear

I have a Mac Pro with multiple displays in a somewhat unusual arrangement:

I’m finding that the right-click context menus in the Projucer will flash momentarily and then disappear if the main window overlaps any of the following areas (red):

Just a minor annoyance - not worth focusing any significant energy on it - but thought it was worth mentioning.

OS X 10.11.6
Projucer 4.2.3 (from juce.com zip)
Mac Pro 4,1
Mixed GFX vendors (all vanilla Apple cards)

First of all: what are you doing that requires four monitors?!?!? :joy:

Tried to reproduce this on a three monitor setup. But I couldn’t reproduce it.

Mostly film scoring work, but it makes a great rig for JUCEing too - I love portrait displays for music scores / plugin windows / API reference / forum etc.

I’ve figured out that it only happens when I have BetterSnapTool running and only affects right-click (not ctrl-click) input.

Seems JUCE may not always play nice with os x assistive devices as this other thread on issues with Synergy (another app I use) also suggests.

This thread is pretty old now, but I have stumbled over the issue myself using BetterSnapTool and just wanted to chime in with what I’ve found:

Immediately after an initial click that triggers a popup menu, the exitModalState() for that menu gets triggered via the following sequence:

juce::PopupMenu::HelperClasses::MenuWindow::hide(juce::PopupMenu::Item const*, bool) 
juce::JuceNSWindowClass::canBecomeMainWindow(objc_object*, objc_selector*)
-[NSWindow(NSWindowAccessibility) accessibilitySubroleAttribute] ()

I don’t exactly know what accessibilitySubroleAttribute is trying to do here, and of course Apple’s docs are pretty sparse on that. But that’s the sequence that forces the popup to immediately get dismissed.

The followup question from this is: Is it correct that JuceNSWindowClass::canBecomeMainWindow() calls sendModalInputAttemptIfBlocked()? Naively I would expect that a method that returns a BOOL like this would simply return a value and not have such a side-effect. And presumably that’s the assumption that accessibilitySubroleAttribute is making as well. Is there some other place that the sendModalInputAttemptIfBlocked() could be called instead?

I have now discovered through some trial and error that if I override JuceNSWindowClass::isAccessibilityElement and return NO that I can prevent the instant popup dismissal. Obviously this is not ideal, since it means that the main JUCE window is no longer participating in accessibility. Then again, it’s not much of a loss, since due to JUCE’s architecture, it’s not navigable via accessibility anyway. [See this discussion: Juce Accessibility].

I’m curious if a change like this would affect anyone and if there’s some better approach that could be taken to handle the problem.

HI. IF the Juce Window itself is unnavigable, it wouldn’t make a difference. In fact, it may be more useful if the popups were to extantiate a Dialog, Alert or a popup menu of some kind. I am thinking if JuceNSWindowClass::isAccessibilityElementcould be made to temporarily remove until the popup is dealt with by the user, then it could help. Cheers!

Ah… interesting idea. That might be possible. Thanks!