Change Details

Ensure that there isn't a race condition with the isVisible check. I.e is QEvent::Close always sent _before_ the menu is actually closed despite the documentation stating "was" not will be (as far as I can tell it is). >Widget was closed (QCloseEvent). Can the menu become closed/invisible before we are done dealing with the event or does it wait for us to deal with it? I tested it by by sleeping for 5 seconds before the isVisible test and the menu didn't close until after. But that doesn't prove it conclusively or for all cases.

Ensure that there isn't a race condition with the isVisible check. I.e is QEvent::Close always sent _before_ the menu is actually closed despite the documentation stating "was" not will be (as far as I can tell it is). >QEvent::Close | Widget was closed (QCloseEvent). Can the menu become closed/invisible before we are done dealing with the event or does it wait for us to deal with it? I tested it by by sleeping for 5 seconds before the isVisible test and the menu didn't close until after. But that doesn't prove it conclusively or for all cases.

Ensure that there isn't a race condition with the isVisible check. I.e is QEvent::Close always sent _before_ the menu is actually closed despite the documentation stating "was" not will be (as far as I can tell it is). >QEvent::Close | Widget was closed (QCloseEvent). Can the menu become closed/invisible before we are done dealing with the event or does it wait for us to deal with it? I tested it by by sleeping for 5 seconds before the isVisible test and the menu didn't close until after. But that doesn't prove it conclusively or for all cases.