I can't reproduce it on the other two OS'es but this may be because I just can't click fast enough between the "Saving" and "Inspecting" dialogues. Is the time between them clickable on Mac? It looks like 200 ms on Win/Linux. Is window close actionable when the "Saving" and "Inspecting" windows have focus?    

What happens when you want to save the project, if you File > Close or File > Exit instead? That works on Windows/Linux - you just get Save Changes, choose the location and the project closes after save. Can you remind me what File > Close does on Mac?

Bug 44 is I think about threading not being safe enough to allow doing things in two projects at once.

(In reply to comment #1)
OK, we're going to have to change the title and steps to reproduce for this bug.

Many dialogs on Mac are non-modal (?). Import, Save Progress and Project Data Check are the ones I've found so far, as well as (apparently) all the progress dialogs for the effects (built-in, AU and Nyquist). Menus are disabled (so you can't do command-W to close a window) but the project window close / minimize / zoom buttons are available. In fact you can bring the project window to the front during an import and close the project window during an import! Of course Audacity crashes in this situation.

This goes all the way back to 1.3.0b

So what I was probably doing was clicking the project window close box pretty much simultaneously with the appearance of the project data check dialog. On Mac at least there seems to be a delay before the appearance of a progress dialog  - as if it waits a second or two and then decides the process is long enough to warrant putting up a dialog. So I was probably closing the project window in the middle of the project data check.

It seems to me that all those progress dialogs should not allow the project window to be brought to the front, nor allow the project window close box to respond to a click.

At lot of this could be put down to user stupidity - of course you don't close the project window in the middle of an import or the application of an effect. But after the save progress dialog goes away it looks like it's safe to close the project when it's not.

> What happens when you want to save the project, if you File > Close or File >
> Exit instead? That works on Windows/Linux - you just get Save Changes, choose
> the location and the project closes after save. Can you remind me what File >
> Close does on Mac?

Yes, those work as expected - the "save changes?" dialog appears, the save takes place then the project window closes and Audacity quits (if you did Audacity > Quit).

(In reply to comment #2)
> Many dialogs on Mac are non-modal (?). Import, Save Progress and Project Data
> Check are the ones I've found so far, as well as (apparently) all the progress
> dialogs for the effects (built-in, AU and Nyquist). Menus are disabled (so you
> can't do command-W to close a window) but the project window close / minimize/
> zoom buttons are available. In fact you can bring the project window to the
> front during an import and close the project window during an import! Of 
> course Audacity crashes in this situation.
Is the availability of the window buttons when there is a progress or other dialogue within the app "normal" on Mac? Or is it an issue with us?     


> So what I was probably doing was clicking the project window close box pretty
> much simultaneously with the appearance of the project data check dialog. On
> Mac at least there seems to be a delay before the appearance of a progress
> dialog  - as if it waits a second or two and then decides the process is long
> enough to warrant putting up a dialog. So I was probably closing the project
> window in the middle of the project data check.
Do you still crash it you wait for the "Inspecting" dialogue to appear fully? 

I've referred to this double dialogue in http://bugzilla.audacityteam.org/show_bug.cgi?id=200#c3 (multiple dialogues that are part of the same overall process).    

 
> At lot of this could be put down to user stupidity - of course you don't close
> the project window in the middle of an import or the application of an effect.
> But after the save progress dialog goes away it looks like it's safe to close
> the project when it's not.
I would argue that the app should exit cleanly if there isn't a force quit e.g if there is a system shutdown call the app should cancel what it is doing and ask about unsaved changes. This works safely on Linux - Leland spent a whole weekend on it once, IIRC.  

What about your crash on File > Exit after the orphaned files dialogue in http://bugzilla.audacityteam.org/show_bug.cgi?id=137#c24 ? Is that dialogue still open when that happens? That dialogue should disappear when you click OK.

(In reply to comment #3)
> Is the availability of the window buttons when there is a progress or other
> dialogue within the app "normal" on Mac? Or is it an issue with us?   

I believe it's an issue with us. The only other app I can test with that puts up progress dialogs is Photoshop. In that case the progress dialog appears to be modal - you cannot bring the main editing window to the front while the progress dialog is displayed. Note that in our case not only are the window buttons available, but the project window can actually be brought in front of the progress dialog.

> Do you still crash it you wait for the "Inspecting" dialogue to appear fully? 

That's hard to do, as that dialog flashes by quite quickly even for a very large project.

> I've referred to this double dialogue in
> http://bugzilla.audacityteam.org/show_bug.cgi?id=200#c3 (multiple dialogues
> that are part of the same overall process).  

Yes, I think it would be a better user experience if those two processes were combined into one progress dialog.

> I would argue that the app should exit cleanly if there isn't a force quit e.g
> if there is a system shutdown call the app should cancel what it is doing and
> ask about unsaved changes.

It's not a shutdown call, though. It's just a closing of the project window. The "save changes" dialog does appear since the project data check is not complete. I'd argue that, if we're not going to make those progress dialogs modal, then we should trap that action and throw an error - "sorry, you cannot close the project while <x> is in progress".

> What about your crash on File > Exit after the orphaned files dialogue in
> http://bugzilla.audacityteam.org/show_bug.cgi?id=137#c24 ? Is that dialogue
> still open when that happens? That dialogue should disappear when you click 
> OK.  

Yes, the dialog disappears. That crash is, AFAICT, this crash and has nothing to do with the crash recovery process, and I'll note that in that bug.

It's a bit hard to get to grips with this, not being on a Mac. 

Is this problem specific to closing a project before Audacity has finished its inspection? Or is the issue more general - while there is an effect progress window open, you can bring the main project window to front, click window close and crash at some subsequent stage? If so then I would still say, rather than "sorry, you can't close", it might be a longer term aim if Audacity could cancel what it was doing and offer to save changes. 

And this isn't (in effect) another "quit on empty project" problem, so it is not solved by the fix for bug 337?

(In reply to comment #5)
> Or is the issue more general - while there is an effect progress
> window open, you can bring the main project window to front, click window close
> and crash at some subsequent stage?

Almost. With *any* progress window visible you can click on the project window to bring it to the front, click the close box, the "save changes" dialog appears. If you click "Yes" or "No" (both of which close the project window) Audacity crashes right then. Sometimes it's a crash, sometimes it's a hang and you have to force quit.

So on Windows and Linux these progress dialogs are modal, and you can't bring the project window to the front?

> And this isn't (in effect) another "quit on empty project" problem, so it is
> not solved by the fix for bug 337?

No. I've tested with 1.3.13rc1 and the problem persists.

(In reply to comment #6)

Mid air collisions (two) again!  

> With *any* progress window visible you can click on the project window
> to bring it to the front, click the close box, the "save changes" dialog
> appears. If you click "Yes" or "No" (both of which close the project window)
> Audacity crashes right then. Sometimes it's a crash, sometimes it's a hang 
> and you have to force quit.
Thanks, Bill. I've changed the bug title to a slightly more economical "Crash/hang closing project window when progress dialogue running". We don't need "On Mac" as it is in the OS info. I guess it's another result (like bug 44) of not having a full modal block.   

 I trust that e.g. in: 

1 New project
2 Generate tone
3 Effect > Compressor (leave dialogue open without doing anything in it)
4 File > Close 

that you can save or exit cleanly? I see you have done a release note (thanks) but I wanted to ask you if it needed to be wider than "progress dialogues". 

> on Windows and Linux these progress dialogs are modal, and you can't bring
> the project window to the front?
There is nothing you can do in the active project except close the progress dialogue (or on Ubuntu, also resize/minimise/maximise the main project window). You cannot close the main window on either OS. 

If you have another project open while the progress is running in the first project - 

* on Ubuntu you can task switch to that other project with ALT - TAB or click 
the taskbar button to bring it to front, but window operations are again limited to minimise/maximise or resize. 

* On Windows 7 you can only bring up the other project with the taskbar and nothing else at all.

(In reply to comment #7)
> I trust that e.g. in: 
> 
> 1 New project
> 2 Generate tone
> 3 Effect > Compressor (leave dialogue open without doing anything in it)
> 4 File > Close 
> 
> that you can save or exit cleanly? I see you have done a release note (thanks)
> but I wanted to ask you if it needed to be wider than "progress dialogues". 

The Compressor dialog itself appears to be modal (as are all effect dialogs) - you cannot bring the project window to the front and the window widgets are inactive. File > Close and Audacity > Quit Audacity are greyed out in the menus. So in this case there is no opportunity to close or exit.

Speaking specifically about Mac here...

As Bill mentioned, it seems that the current "semi-modal" issue has been around for a long time.  Prior to 1.3.5d, the progress dialogs were completely modeless, so all menu options were available.  With 1.3.5d, only the application and help menus are available.

At first glance, I believe this is because the progress dialogs are only simulating a modal effect by disabling other windows while the progress dialog is active.  Unfortunately, since it's not a true modal dialog, the items on those 2 Mac menus remain enabled.

I'll see if there's an easy way to correct it.

Thanks, Bill. I generalised the end of the release note from "clicking the project window close box" to "closing the project window", as I assume 
File > Close or Audacity > Quit Audacity would have the same problem? Please change it if that's not true.

Created attachment 149 [details]
Disable parent window's close button and application's Quit menu

This should help out with the problem.  It's a bit of a kludge (I would have liked to have found a wxWidgets function that REALLY disabled the parent window, but I couldn't find one), but it seems to do the trick.

Bill, I didn't know if you could build Audacity with the patch, so I uploaded a test version to:

http://audacity.homerow.net/cgi-bin/dl?experimental/audacity-macosx-ub-1.3.13.zip

(In reply to comment #11)
I tried the patched version. You can still bring the project window to the front but the close box is indeed inactive. The project window widgets light up even when the project window is behind the progress dialog. The close box does not respond to clicks but the minimize and zoom buttons do, whether the window is behind or in front of the progress dialog.

Testing with the "Saving Data" / "Inspecting Data" dialog pair, clicking the project window close box as soon as the "saving" dialog disappears does not close the window.

The Quit menu item is initially disabled. If you do Audacity > Preferences > OK the Quit menu item becomes enabled (not grey), but still does not function - you can select it, it flashes, but Audacity does not quit.

So it looks like this patch prevents the crash, at the (minor?) expense of some non-standard Mac GUI behaviour.

(In reply to comment #12)
> (In reply to comment #11)
> I tried the patched version. You can still bring the project window to the
> front but the close box is indeed inactive. The project window widgets light up
> even when the project window is behind the progress dialog. The close box does
> not respond to clicks but the minimize and zoom buttons do, whether the window
> is behind or in front of the progress dialog.
> 
Hmmmm...I'm not certain I can do anything about the those.  I may be able to keep the z-order, but I'm not so sure about the minimize and zoom fellas.  It's just that wxWidgets doesn't provide a full window disabler for the Mac.

> The Quit menu item is initially disabled. If you do Audacity > Preferences > OK
> the Quit menu item becomes enabled (not grey), but still does not function -
> you can select it, it flashes, but Audacity does not quit.
> 
Eeewwww...I didn't notice that.  I'll check it out.

Okay, I lied.  I believe(In reply to comment #12)
> (In reply to comment #11)
> I tried the patched version. You can still bring the project window to the
> front but the close box is indeed inactive. The project window widgets light up
> even when the project window is behind the progress dialog. The close box does
> not respond to clicks but the minimize and zoom buttons do, whether the window
> is behind or in front of the progress dialog.

Okay, I lied.  I believe I can provide a truly modal-like experience.  Still have to figure out the "Quit" menu item though.

Created attachment 150 [details]
Really disables the parents this time...

This one really does disable the parent window now.  It also disables Quit and Preferences menu items.  There are several menus that are available that normally aren't when a modal dialog is displayed, but they should be benign.  (Hopefully anyway since I'm out of ideas ;-))

Uploaded a new experimental binary to:

http://audacity.homerow.net/cgi-bin/dl?experimental/audacity-macosx-ub-1.3.13.zip

I've promoted this to P2 as the bug is much more pervasive than that originally presented (and also because we have it seems an adequate solution to it). We've just had an (assumed) example on feedback@ of this bug. 

Leland, re: bug 44, is File > New disabled?

(In reply to comment #17)
> Leland, re: bug 44, is File > New disabled?

Woohoo!  Yepper that old bug has finally been squashed!

(In reply to comment #16)
The latest experimental binary works much better at making those progress dialogs more modal-like. When attempting to bring the project window to the front while a progress dialog is on screen you get a beep and no action. The window widgets do not light up. The Preferences and Quit menu items are disabled. Attempting to use the Window menu to bring the project window to the front also results in a beep and no action.

Under the Help menu you can do Run Benchmark then click Run in the benchmark dialog and nothing bad seems to happen. Help > Audio Device Info brings up that window with no ill effects. Help > Show Log shows the log window, however when you do Log > Close the "minimal menu bar" remains until the effect finishes or you cancel the effect - the proper menu bar returns at that point.

Now the bad news - it is still possible to close the project window between the "saving" and "inspecting" dialogs if you're fast enough. While the "saving" dialog is on screen position your mouse over the project window close box. As soon as the close box becomes active, click on it - the "save changes" dialog appears. After the crash (assuming you click "Yes" or "No" in the save dialog) there is a _data folder but no .aup file in the save location. On letting this process complete I see that there appears to be three dialogs - "save", "cleaning up cache directories" and "inspecting". Between each dialog there is a moment when the project window is in front and the window widgets are active.

(In reply to comment #19)
> (In reply to comment #16)
> 
> Now the bad news - it is still possible to close the project window between the
> "saving" and "inspecting" dialogs if you're fast enough. While the "saving"
> dialog is on screen position your mouse over the project window close box. As
> soon as the close box becomes active, click on it - the "save changes" dialog
> appears. After the crash (assuming you click "Yes" or "No" in the save dialog)
> there is a _data folder but no .aup file in the save location. On letting this
> process complete I see that there appears to be three dialogs - "save",
> "cleaning up cache directories" and "inspecting". Between each dialog there is
> a moment when the project window is in front and the window widgets are active.

Yea, I knew that would still be a problem.  I was just hoping that nobody was quick enough.  ;-)  The same thing should be possible on Windows and Lnux as well (fixin' to try it).

Not sure what to do about it (yet).

(In reply to comment #20)
> Yea, I knew that would still be a problem.  I was just hoping that nobody was
> quick enough.  ;-)  The same thing should be possible on Windows and Lnux as
> well (fixin' to try it).
> 
> Not sure what to do about it (yet).

Would it be possible to combine those three dialogs into one? That is, one dialog with changing messages? That way there'd be no chance for the project window to come to the front before the entire save/check process was complete.

(In reply to comment #20)
> The same thing should be possible on Windows and Lnux as
> well (fixin' to try it).
> 
Yep, was able to recreate on Windows as well by pressing CTRL+Q while the saving progress dialog is displayed and hold them down until after it goes away.  The crash is in the same place as it is on the Mac, but that's not really the problem.  I'm sure it the small window of time between when the save progress dialog disappears and the inspect function creates another progress dialog.  During the period, the main window goes modeless.

(In reply to comment #21)
> (In reply to comment #20)
> > Yea, I knew that would still be a problem.  I was just hoping that nobody was
> > quick enough.  ;-)  The same thing should be possible on Windows and Lnux as
> > well (fixin' to try it).
> > 
> > Not sure what to do about it (yet).
> 
> Would it be possible to combine those three dialogs into one? That is, one
> dialog with changing messages? That way there'd be no chance for the project
> window to come to the front before the entire save/check process was complete.

In the same way we make the progress dialog "modal", we could probably make the entire Save process "modal" by disabling windows as the beginning of the Save process and then re-enabling at the end.

Don't know if it'll work, but I'm gonna give it a try.

Leland, I don't know Mac, but scanned your patch.

1) I'd enclose the new extra includes with "#if defined(__WXMAC__)", too. 

2) Do you really need to include object.h? wxObject is the base class of all wxWidgets classes, so I'm surprised it's not already included indirectly.

Otherwise, I say commit it.

(In reply to comment #24)
> Leland, I don't know Mac, but scanned your patch.
> 
> 1) I'd enclose the new extra includes with "#if defined(__WXMAC__)", too. 
> 
Okay.

> 2) Do you really need to include object.h? wxObject is the base class of all
> wxWidgets classes, so I'm surprised it's not already included indirectly.
> 
Noper, not really.  I'll remove it.

Leland

(In reply to comment #18)
> > Leland, re: bug 44, is File > New disabled?
> Woohoo!  Yepper that old bug has finally been squashed!
Only partially? Can't you still use shortcuts on Mac as well as Windows? 

Even if we committed this as it is now, we could reasonably drop back to P3 I think for the case where you click between the component progress dialogues for project saving.

(In reply to comment #26)
> (In reply to comment #18)
> > > Leland, re: bug 44, is File > New disabled?
> > Woohoo!  Yepper that old bug has finally been squashed!
> Only partially? Can't you still use shortcuts on Mac as well as Windows? 
> 
I meant that bug 44 was finally squashed...at least with this patch on I can no longer get 2 imports going at once.

> Even if we committed this as it is now, we could reasonably drop back to P3 I
> think for the case where you click between the component progress dialogues for
> project saving.

Yepper.

Created attachment 155 [details]
Incorporates Vaughan's suggestions

(In reply to comment #27)
> I meant that bug 44 was finally squashed. 
Just don't get it. I applied your latest attached patch on Windows Unicode Release. Easy to get two imports going at the same time. Import an hour long file using On Demand. All menus are enabled. File > New , File > Import > Audio another hour long file. Task switch between them to look at each one importing. Are you saying you can't now do that on Mac? Mind you, it appears to run smoothly.   

Looking at your steps in the bug 44, yes that's easy too. Prepare two project windows, set Prefs to copy in, import the first hour long WAV, click the taskbar button of the other project, use your import shortcut and import the other hour long WAV. Freeze and force quit. 

Or have I been hit again by having to do a fresh checkout before changes get compiled in?

Bummer(In reply to comment #29)
> (In reply to comment #27)
> > I meant that bug 44 was finally squashed. 
> Just don't get it. I applied your latest attached patch on Windows Unicode
> Release. Easy to get two imports going at the same time. Import an hour long
> file using On Demand. All menus are enabled. File > New , File > Import > Audio
> another hour long file. Task switch between them to look at each one importing.
> Are you saying you can't now do that on Mac? Mind you, it appears to run
> smoothly.   

That's a different situation entirely.  On Demand loading would not be considered a blocking action, so you should be allowed to do as many as you like.  Even quitting Audacity if you so choose.

> Looking at your steps in the bug 44, yes that's easy too. Prepare two project
> windows, set Prefs to copy in, import the first hour long WAV, click the
> taskbar button of the other project, use your import shortcut and import the
> other hour long WAV. Freeze and force quit. 
> 
But, this one is definitely a problem on Windows.  Linux blocks the other windows like it should and, with the patch, Mac does now as well.  I'll look into the Windows issue.

(In reply to comment #28)

from Leland Lucius <leland@audacityteam.org> 2011-04-01 23:07:45 EDT ---
> Created an attachment (id=155)
> Incorporates Vaughan's suggestions
> 

Thanks. Good by me. I say go ahead and commit that even while other stuff pending (per comment 30).

Committed.  I have an idea for the Windows problem too, but will attach another patch as I think it needs to be tested and really thought about some.

Created attachment 157 [details]
This seems to fix the keyboard interaction on Windows

Okay, Gale.  Give this one a try.  You should no longer be able to use keyboard shortcuts while the progress dialog is active.

(In reply to comment #30)
> On Demand loading would not be considered a blocking action
I understand that, but the bug steps don't actually make that clear. And I understand that some time we really want to allow multiple copy-in imports and multiple other actions, but block it now because not threadsafe?   

So we're happy that five OD imports at the same time in different projects is OK (because threadsafe?) How about one OD import and one copy-in import (toggle the pref in the new warning before the second import)? Seems to be OK but I did not wait for it to finish...

Moved to DEVEL - FIX MADE re Leland's r11068 commit. 

> Okay, Gale.  Give this one a try.  You should no longer be able to use keyboard
> shortcuts while the progress dialog is active.
Will try when I can. Probably we should now discuss this and whether simultaneous OD and copy-in imports are OK in bug 44.

(In reply to comment #34)
> (In reply to comment #30)
> > On Demand loading would not be considered a blocking action
> I understand that, but the bug steps don't actually make that clear. And I
> understand that some time we really want to allow multiple copy-in imports and
> multiple other actions, but block it now because not threadsafe?   
> 
I'm not entirely certain multiple non-OD imports every really worked right...well, not on the Mac at least.  If you got 2 going together, Audacity would seem to hang until both of them were complete.

> So we're happy that five OD imports at the same time in different projects is
> OK (because threadsafe?) How about one OD import and one copy-in import (toggle
> the pref in the new warning before the second import)? Seems to be OK but I did
> not wait for it to finish...

Where do you come up with these scenarios?!?!?!  :-D

That's a really good question and one I just don't know how to answer, or rather, it makes my head hurt trying to figure out the correct answer.  :-)

(In reply to comment #36)
See http://bugzilla.audacityteam.org/show_bug.cgi?id=44#c2

Created attachment 176 [details]
Refresh Leland's patch to block shortcuts in a new window

should now apply correctly to current src/widgets/ProgressDialog.cpp

@Leland, I tried your patch for Windows (reattached as "Refresh Leland's patch to block shortcuts in a new window", which I hope I inserted in the correct place for the current file). This seems to work fine - I can no longer use a shortcut in a second project window to import a file or do anything else while a file is importing in the other window. 

@Leland and Bill, have we still got the remaining issue in the steps to repro where you can quit in-between "Saving project data files" and any subsequent dialogues and crash? I am unclear from the comments in this bug if http://code.google.com/p/audacity/source/detail?r=11068 fixed this or not. I did try on Windows holding down CTRL + Q while "Saving project data files" was running, but Audacity seemed to quit cleanly and the .aup and _data folder was saved correctly.

(In reply to comment #19)
Bill wrote:
> it is still possible to close the project window between the
> "saving" and "inspecting" dialogs if you're fast enough. While the "saving"
> dialog is on screen position your mouse over the project window close box.
Bill has confirmed this is sill true at date of writing and will cause a crash. He now confirms that if you click "Yes" in the Save Changes dialog, the .aup is properly created. If you click "No" in the Save Changes dialog, the .aup file is not created, thus destroying the project. 

As this is now a fringe case, demoted to P3 "Crash closing project window between save project dialogues" with a specific release note.  

Leland will I assume attempt to fix this in future by making the entire Save process "modal" by disabling windows as the beginning of the Save process and then re-enabling at the end. Or it can be done by combining the component save dialogues into one.  

Would be good to see attached "Refresh Leland's patch to block shortcuts in a new window" applied if it is correct (which is actually for a Windows issue in bug 44).

(In reply to comment #40)

Applied the patch.

(In reply to comment #41)
Assuming this patch was applied in time for the Mac nightly Feb 14 2012 03:15 GMT, then it does not address the (Mac only?) issue of closing the project window between the 'saving' and 'inspecting' dialogs. As indicated in comment 19 and comment 40 one can still crash Audacity by this method, and lose one's work by selecting 'No' in the 'Save Changes?' dialog that results.

(In reply to comment #42)
The patch appears to make progress dialogs behave like modal dialogs per my comment 19:
... works much better at making those progress
dialogs more modal-like. When attempting to bring the project window to the
front while a progress dialog is on screen you get a beep and no action. The
window widgets do not light up. The Preferences and Quit menu items are
disabled. Attempting to use the Window menu to bring the project window to the
front also results in a beep and no action.

Under the Help menu you can do Run Benchmark then click Run in the benchmark
dialog and nothing bad seems to happen. Help > Audio Device Info brings up that
window with no ill effects. Help > Show Log shows the log window, however when
you do Log > Close the "minimal menu bar" remains until the effect finishes or
you cancel the effect - the proper menu bar returns at that point.

(In reply to comment #42)

Changed the Platform for this bug because I didn't realize this contained two completely different patches, for different platforms. I saw that the first active one had not been made obsolete, although it should have (and I now have), by the "Incorporates Vaughan's suggestions". So I thought I need only apply the last one, "Refresh Leland's...", that it had cumulated all the fixes for this bug. But it was only the Windows fix.

So the good news is that's why it didn't fix the Mac problem -- completely different bug. I've now applied the "Incorporates..." so please test on Mac.

(In reply to comment #44)
Behaviour is the same in the Feb 15 Mac nightly. Did that patch make it in in time for that nightly build?

(In reply to comment #45)
> Behaviour is the same in the Feb 15 Mac nightly. Did that patch make it in in
> time for that nightly build?
According to the timestamp on the SVN commit (01:16 GMT/UTC 15 Feb) , should be in the Mac Nightly build...

The Windows Bug 44 (to which Leland's patch to block shortcuts in a new window should have been posted) has been resolved-fixed, so changed platform of this bug back to OS X.

Paul has confirmed r11501 ( http://code.google.com/p/audacity/source/detail?r=11501 ) was in the Feb 15th 03:15 GMT build, so unless there is some other explanation, patch should be declared a failure and bug reopened.

REOPENED as Bill has stated you can still crash by closing the project too soon after the saving project data files dialogue closes. 

But re-reading this I am confused. Steps to repro suggests that clicking the X button on the window immediately an effect completes leads to a crash when you press either Yes or No on the ensuing Save Project dialogue. Why - if you have other projects open - is this only a loss if you said "No" to saving? 

Release Note has a different scenario where you explicitly decide to save a project but Audacity crashes if you click the X immediately the "saving project data files dialogue" completes. And it says you don't lose data if you say yes to saving the project. Maybe that sentence needs deleting?      

So are both these scenarios still valid? I have tried to reproduce them again on Windows 7 by holding CTRL + Q or clicking Red X just before the effect or save project data files dialogs complete, but get no crash. Is there an inspection dialogue after any effect?

(In reply to comment #49)
Steps to repro are wrong, release note is right (on Mac, at least).

The issue with effect progress dialogs was that you could close the project window (or even bring it to the front) while an effect was processing (progress dialog was on screen). This has been fixed.

There is no "inspecting" dialog after an effect finishes.

If you close the project window (or Quit Audacity) after the "Saving" progress dialog closes and before the "inspecting" dialog appears, the project is still dirty and the "Save Changes" dialog appears. If you say "No" then the AUP will not be written and the project is destroyed. If you say "Cancel", the project does not close, the "inspecting" progress dialog appears and no crash occurs. If you say "Yes" the AUP is written then Audacity crashes. I can do this reliably on my Mac.

Comment 22 is relevant here. It appears that "the small window of time between when the save progress dialog disappears and the inspect function creates another progress dialog" allows the project window to go "non modal" and respond to close events.  The save process then creates the inspecting dialog, and that is where the crash occurs.

All my testing has been done with one project open. It has been a new project of significant size so that the "saving" and "inspecting" dialogs are visible for several seconds.

(In reply to comment #50)
OK, Bill, thanks. Replaced the steps to repro and (I hope) made the Release Note clearer.

Took some doing, but I was just able to reproduce the crash.  Off to see if it can be fixed.

Fix committed in:

https://github.com/audacity/audacity/commit/0e12ab6760448519243a7a41c1b31a90ee719b69

After wx3, this now causes a problem with proper focus handling (at least on Windows), so reopening until I can come up with something better.

Actually, this problem may not even be repeatable on wx3, so now need to go back and try to recreate it on wx2, then retry on wx3.

"Unfixed" :-) committed in https://github.com/audacity/audacity/commit/eabe01455116174c588cd2d49cba2bbe504bd068

A bit of explanation from the comments I left in the source:

I added this to "fix" bug #334.  At that time, we were on wxWidgets 2.8.12 and
there was a window between the closing of the "Save" progress dialog and the
end of the actual save where the user was able to close the project window and
recursively enter the Save code (where they could inadvertently cause the issue
described in #334).

When we converted to wx3, this "disabler" caused focus problems when returning
to the project after the save (bug #1172) because the focus and activate events
weren't being dispatched and the focus would get lost.

After some testing, it looks like the window described above no longer exists,
so I've disabled the disabler.  However, I'm leaving it here in case we run
into the problem in the future.  (even though it can't be used as-is)

Works ok for me on El Capitan audacity-macosx-r96d2e66-2.1.2-alpha-10-oct-15 with the exception that try as I may I can not get the "Inspecting Project Data File" popup to come up. The window close button is grayed out until the save is finished.

RESOLVED - QUICKFIXED
(In reply to Leland Lucius from comment #20)
> The same thing should be possible on Windows and Linux 

So I tried it on those two platforms but did not get a crash.