mozille.exe -profilemanager mozilla.exe -console -profilemanager When I try to close profile manager (by double-clicking on a profile name or by clicking "start mozilla"), it takes about a second for the dialog to disappear. This is a little confusing. (If making the window disappear more quickly would hurt startup performance, feel free to wontfix.)

nav triage team: Reassigning to ccarlen

When you click on the "Start" button in the dialog, the profile is set and this is a fair amount of work. For other reasons, I am investigating closing the dialog before doing any of this work. That would solve this. While the total time would not be much different, the dialog would disappear instantly.

Profile Mgr has up to now, posed its modal dialogs by using appshell and spinning up an event loop. The front-end code exits the modal loop by calling Quit() on the appshell. The current profile is set after the confirm button is clicked but before the dialog is closed - hence the delay described here. While this delay is a small problem, using appshell to pose dialogs this way is a big problem. When nsAppShellService::Quit is called in exiting the modal loop, appshell's mNativeAppSupport is killed off. The patch here uses window watcher to pose the dialogs and dialog param blocks to get data info from the dialog. The dialog can be posed, closed, then interrogated, then the action is taken. This cleans up the back end considerably.

Adding Dan & Alec for r and sr. Ignore the .js changes in the 2nd patch which are in the 3rd.

ok, I think I'm understanding where the actual fix is :) sr=alecf

-> 0.9.3 Because the patch is sizable but does not fix a crucial bug, but is more of a structural improvement, I doubt it's going to be allowed in any time soon.

changing QA contact

Much of this work has been done as part of other things. The final bit will have to wait until 0.9.4.

This patch was incorporated into another bug (bugscape 8046) which already is reviewed. That makes this one moot. Problem will be solved when that's checked in.

I think "worksforme" or "fixed" would be a more appropriate resolution.

Marking wfm.

Verified (problem solved when fix for bugscape bug 8046 is checked in)