you hit on a link with unknown mime-type or a download link. now comes the dialog asking you how you want to treat the file, one is to safe it to disk. you hit the safe button, the safe as dialog appears. now my point: the mime-type dialog isn't a window belonging to the browser-window, but afterwards the safe as does. I startet noticing that as I tried a new WindowManager: http://www.students.tut.fi/~tuomov/ion/ it doesn't have overlapping windows, but tabbed ones. using Mozilla in the described ways results in the first window poping up in an own tab in front of mozilla, and the second one pops up (after pressing save) it pops up in the original mozilla-tab.not quiet intuitive;-)

-> File Handling

Wilfried, is this still a problem for you in Mozilla 1.0 or Mozilla 1.1alpha?

I see this too (any windowmanager that somehow ties windows to their parents, eg AfterStep, will demonstrate this problem).

So the problem is that in nsHelperAppDlg.js the dialog we put up is not modal and is not parented to anything.... This is a problem on all platforms -- one can pop up as many helper app dialogs as one wants off one page, and as many filepickers as one wants off the helper app dialog (the filepicker is modal to the browser, not to the helper app dialog). Is there a reason this dialog is not modal? On some windowmanagers this bizarre modality setup leads to very odd behavior (like the filepicker opening on a different desktop from the helper app dialog).

This makes the helper app dialog dependent on the main window (but not modal). It makes the filepicker modal to the helper app dialog (which makes a lot more sense to me than the current setup, since otherwise one can open multiple filepickers, cancel one of them (dismissing the helper app dialog) and then cancel the others, which is weird).

Are you sure you want to go there, Boris? There was a time where we had major problems with the parenting and/or modality of the helper app dialog. The problem, as I recall, was that if you closed the parent browser window, then we would crash when we closed the helper app dialog (or something like that). The next issue is that promptForSaveToFile is sometimes called without the helperApp dialog ever being shown, and almost always (I think) called after the helper app dialog is closed (in which case "this.mDialog" is null). So the change to that code doesn't sound right to me. Lastly, this window parenting issue is very platform dependent so any change in this area would have to be thoroughly tested on all platforms to make sure they can all deal with it. Maybe the thorough testing would resolve the other issues, too. It could be that the crash problem we saw long ago has been resolved by subsequent changes to xul/widget code. I'd still like discussion of the second point, however (the change of parent when this.mDialog is null).

> Are you sure you want to go there, Boris? Of course not. ;) I do think that the current setup needs fixing, though. Ideally, I would like to make the helper app dialog modal to the main browser window, but that seems to break things pretty badly, so.... > The next issue is that promptForSaveToFile is sometimes called without the > helperApp dialog ever being shown Hmm... good point. That happens in the "do not ask" case for "save as"; I forgot about that... The correct solution there would be to use the aContext when this.mDialog is null, I think... That's what this patch does. I agree that this should be tested carefully and I'll try to find people to test it on the windows and Mac platforms. I just tested on Linux and I get no crash when I open a bunch of helper app dialogs, then close the parent window, then close the helper app dialogs (cancelling some and ok-ing others).

ok, on windows, I observed this behaviour: I opened several save as windows. Then I minimized the parent window: All dialogs were minimized as well. Then I restored the parent window and closed it, all the save as windows were closed as well. Then I chose "Save" from a save as dialog so that the filepicker appeared. Closing the parent window close both the filepicker and the save as dialog. Now, my opinion about this: I don't like non-modal windows closing if the parent closes. I would like this to happen: Save as window independent of parent. Clicking save as closes the save as window, and opens the filepicker, which would also be independent.

OK. I can implement biesi's suggestion from the end of comment 8... It would involve having a non-modal, unparented filepicker, but it could be done. Apart from the technical issues (if any) how does that sound from a UI standpoint? Lori? mpt?

yes, this is a good solution

In Mozilla 1.0 under Linux, I've noticed that the "Enter name of file to save to..." filepicker dialog is modal, and parented to the original browser window, while the "Downloading <filename>" window (which has the "Open using an application" and "Save this file to disk" options) remains active. Each time you click OK, it will pop up ANOTHER filepicker dialog. (However, only the most recent dialog works; the older ones will have no effect on the download.) If the "Downloading <filename>" window remains, the filepicker should be modal and child to THAT window, not its parent. There's no good reason to be modal to the original browser window -- let that window go on its merry way and just remember what was going to be downloaded. It might be a better solution to make the filepicker dialog be non-modal and independent (maybe transient, maybe not?), and having the "Downloading <filename>" window close before opening the filepicker. However, if that window remains on the screen, the filepicker dialog should be modal with that window as its parent window, not the grandparent browser window. Currently, clicking Cancel on the filepicker dialog will cancel the download. There's a good argument to be made for keeping the intermediate window around (with the filepicker modal to it) and returning to the intermediate window on a Cancel from the filepicker. After all, it might not be easy to restart the download (suppose it's a CGI?) and the user might decide they'd rather open it with an application than save the file to disk. Why should the choice to save to disk be irrevocable? One way or the other, the current behavior is flawed and should be changed. (These comments are all based on Mozilla 1.0 -- how much of this is changed since that time?)

None of this has changed since then.

bug 188735 (blocked by this bug) symptoms match bug 257121. would this improved or worsen (or not change) bug 257121?

(In reply to comment #13) > would this improved or worsen (or not change) bug 257121? further, will the patch affect bug 261562 which bug 257121 (possibly incorrectly) blocks?

bug 188735 WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041401 SeaMonkey/2.0a1pre here too, the dialog from file|save page is modal. => WFM feel free to reopen if I misunderstand how to recreate this bug