Closed quickiwiki closed 8 months ago
Thank you for reporting. While the proposed change is a fix, we opted to go for a different change. The general thinking behind the cancel() implementation, is that the user interface shouldn't become unresponsive due to a modal component in a way, that is not easily visible/discoverable by the user.
The Windows implementation sidesteps this issue, by ignoring close and minimise request during modal activity. A change has been released on develop
, which mimicks the Windows behaviour.
https://github.com/juce-framework/JUCE/commit/fb14118771eeb34f51146e23def0a1f94a49fbad
Detailed steps on how to reproduce the bug
I have seen an odd behaviour in the model component manager (ModalComponentManager::ModalItem) that doesn’t seem to be right and causes the modals to be cancelled when the JUCE application is minimised. At its core, componentVisibilityChanged() is called when the application is minimised, and it looks like this:
void componentVisibilityChanged() override { if (! component->isShowing()) cancel(); }
The code above would cancel any modal.
What is the expected behaviour?
Modal windows should not be cancelled on minimise.
Such behaviour can be fixed with an easy change, which might resemble the code below.
void componentVisibilityChanged() override { const auto peer = component->getPeer(); if (! component->isShowing() && !(peer && peer->isMinimised())) cancel(); }
Operating systems
macOS
What versions of the operating systems?
macOS Monterey 12.6.7
Architectures
ARM
Stacktrace
No response
Plug-in formats (if applicable)
No response
Plug-in host applications (DAWs) (if applicable)
No response
Testing on the
develop
branchThe bug is present on the
develop
branchCode of Conduct