Opened 8 years ago

Closed 5 years ago

#12402 closed defect (fixed)

Modeless dialogs without parent don't close properly and crash in wxOSX

Reported by: byte Owned by:
Priority: high Milestone: 3.0.0
Component: wxOSX Version: stable-latest
Keywords: Cc:
Blocked By: Blocking:
Patch: no


Application crashes at exit when wxAboutBox was called with parent == NULL.
Try to remove "this" parameter in dialogs sample, open about dialog and close application.

Attachments (1)

dialogs_about.patch download (989 bytes) - added by disc 7 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 7 years ago by disc

  • Status changed from new to confirmed


Reproducible with 2.9.1 and current svn. The simple and custom about work fine, problems occur with the fancy (Shift+F1) and full (Cmd+F1) one.
One of the ways to reproduce:

Apply attached patch
Build dialogs sample (I used configure/make build method)
Run "open ./"
Press Shift+F1 to open the fancy about
Close the about window using the red close button
Close the main window using the red close button
Click on the "dialogs" app menu (the left one), or "Help" menu ("Dialogs" and "Edit" menu are safe to click)
The app crashes(1).

Sidenote: If after closing both windows (with the app then still active) you go to the Terminal and run open ./ again the earlier closed fancy about box pops up.

Also there are some differences between 2.9.1 and current svn: also clicking on the "Dialogs" menu in 2.9.1 results in a crash, while with svn it's safe to do that.

(1) Call stack:

wxEvtHandler::SafelyProcessEvent(wxEvent&) + 10
wxWindowBase::HandleWindowEvent(wxEvent&) const + 34
wxMenu::DoHandleMenuEvent(wxEvent&) + 141
wxMenu::HandleMenuOpened() + 80
-[wxNSMenuController menuWillOpen:] + 82
-[NSMenu _sendMenuOpeningNotification] + 92
-[NSCarbonMenuImpl _carbonOpenEvent:handlerCallRef:] + 37
NSSLMMenuEventHandler + 404
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1567
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 411
SendEventToEventTargetWithOptions + 58
SendMenuOpening(MenuSelectData*, MenuData*, double, unsigned long, __CFDictionary*, unsigned char, unsigned char*) + 537
DrawTheMenu(MenuSelectData*, __CFArray**, unsigned char, unsigned char*) + 266
MenuChanged(MenuSelectData*, unsigned char, unsigned char) + 470
TrackMenuCommon(MenuSelectData&, unsigned char*) + 1484
MenuSelectCore(MenuData*, Point, double, unsigned long, OpaqueMenuRef**, unsigned short*) + 315
_HandleMenuSelection2 + 465
_HandleMenuSelection + 53
_NSHandleCarbonMenuEvent + 285
_DPSNextEvent + 2304
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
-[NSApplication run] + 821
wxGUIEventLoop::DoRun() + 55
wxCFEventLoop::Run() + 149
wxAppConsoleBase::MainLoop() + 89
wxAppConsoleBase::OnRun() + 26
wxAppBase::OnRun() + 44
wxApp::OnRun() + 29
wxEntry(int&, wchar_t**) + 168
wxEntry(int&, char**) + 63
main + 24 (dialogs.cpp:119)
start + 53

Changed 7 years ago by disc

comment:2 Changed 7 years ago by vadz

  • Milestone changed from 2.9.2 to 2.9.3

2.9.2 is already past

comment:3 Changed 7 years ago by vadz

  • Milestone changed from 2.9.3 to 3.0
  • Priority changed from normal to high
  • Summary changed from Problem with wxAboutBox with parent == NULL under MacOS to Modeless dialogs without parent don't close properly and crash in wxOSX

I see this as well and you don't need to use wxAboutBox() to see it, just this:

  • samples/minimal/minimal.cpp

    a b void MyFrame::OnQuit(wxCommandEvent& WXUNUSED(event)) 
    186186void MyFrame::OnAbout(wxCommandEvent& WXUNUSED(event))
     188    (new wxDialog(NULL, -1, "Parentless modeless dialog"))->Show();
     189    return;
    188190    wxMessageBox(wxString::Format
    189191                 (
    190192                    "Welcome to %s!\n"

is enough.

Just run the sample, press F1 to show the dialog, then close it using mouse. Now close the main frame -- the application doesn't exit but the dialog (or is its zombie?) appears again. Closing it doesn't do anything any more and trying to close the sample from the menu results in a crash with a similar backtrace.

Unfortunately I don't know the details of TLW implementation in wxOSX well enough to do anything about this.

comment:4 Changed 5 years ago by csomor

we have three different issues

  • wxApp::MacReopenApp was changed 7 years ago to also Show hidden windows - non-modal dialogs get shown again in this situation ...
  • closing the main frame didn't remove its menubar
  • the app isn't exited when the main frame is closed because wxTopLevelWindowBase::IsLastBeforeExit returns false since the hidden non-modal dialog vetoes via ShouldPreventAppExit (default return value = true)

comment:5 Changed 5 years ago by vadz

Thanks for looking into this! The dialog being shown again threw me off track but actually this seems to be the only thing wrong here, as hidden TLWs should prevent the application from exiting and do this under MSW too.

I don't know if the crash is still reproducible after r74060 but if not, this can probably be closed.

comment:6 Changed 5 years ago by csomor

r74060 is dealing with the first issue, I'll commit another for the second, but I really think the app should be closed - so even this happens under msw as well as this is generic code, I think it is wrong ...

comment:7 Changed 5 years ago by SC

(In [74061]) make sure we have a default handling the quit command, see #12402

comment:8 Changed 5 years ago by SC

(In [74062]) using an empty default menu bar when no menubar is available, see #12402

comment:9 Changed 5 years ago by vadz

I think the typical use case for modeless dialogs is to create them with some other frame as parent. And if you do this, then everything works as expected, at least under MSW, because the dialog will be destroyed when its parent is.

OTOH, creating a hidden TLW may be used on purpose to prevent the application from terminating, e.g. it can run in the background until something happens (timer, network, ...).

So I don't think we should close the hidden TLWs without a parent, this would be backwards incompatible and doesn't solve any real problem AFAICS.

I didn't test your last commits yet but if they behave as I think they do, then this ticket seems to be fixed to me.

comment:10 Changed 5 years ago by csomor

  • Resolution set to fixed
  • Status changed from confirmed to closed
Note: See TracTickets for help on using tickets.