Trying to save a file in a location where the user doesn't have write access makes Mozilla hang. To reproduce: 1. Go to mozzila.org 2. Click on one of the download links in the lower right 3. Save as... 4. Enter a path that the current user doesn't have write permission for Actual result: Mozilla hangs. Expected result: Permission denied warning, return to file pick dialog Linux 2000.01.12.12

Ouch. On NT, step 4 can be reproduced, but normally the user chooses the drive letter and directory path independently of specifying (or accepting the proposed) filename. Either way, if the directory specified or chosen in the OS-specific "Save As" dialog is unwritable, a warning is put up *by WinNT*, and the user is returned to the "Save As" dialog. I'd expect much the same from the Mac, from inside the OS toolkit. For *nix, there is no standard OS-provided "Save As" dialog, so if Mozilla is providing its own, this will need to be fixed there. Tested with: 2000-01-20-08-M13 nightly binary on Windows NT 4.0sp3 zach@math.berkeley.edu, can you provide a better description for "Mozilla Hangs" as the Actual Result? How bad is the hang - is it necessary to cancel the dialog, kill the Mozilla process, or something in between?

Mozilla hangs = All Mozilla windows are unresponsive and repaint only blank grey. Neither Cancel nor closing window works. Process has to be killed.

Upping severity to CRITICAL based on last coment.

Retested on Linux, this no longer hangs, but on the other hand, while the file is not saved, a Saving File dialog momentarily appears, giving the appearance that the file was saved when it was not. Tested with: 2000-01-22-09-M14 nightly binary on customised Slackware 4.0, fvwm2

Over to valeski for a look, is this backend? m14 to start.

last time I checked warren was our file man.

I think this is a dup of bug 24996.

No, on 2000-01-22 on Linux, a file was saved when permissions allowed, so this can't be bug 24996, which is currently blocking all file saving. Sorry for omitting that detail. Obviously, though, this bug can't be tested so long as bug 24996 exists and is unfixed. More importantly, Mozilla has no business either hanging (original report) giving any appearance of saving a file, or doing nothing if write permissions on the destination directory forbid it; some sort of alert should be presented instead, warning that the file won't be saved at that location. This is being handled on NT by NT's "Save As" dialog, and presumably on Macs by the toolkit "Save As" code (though this should be checked), but on Linux, the save appeared to happen but must have gone to /dev/null.

I still believe the root of bug 24996 is also the problem here. Different manifestations of the same bad code.

Fair enough, but in that case there is still the issue of no alert being given when the file is not saved on Linux (probably all UNIX or at least all GTK). This may be something to be included in the file picker redesign for linux, bug 26480, since this is handled by the native file picker on Win32 and I am almost certain on Mac too.

This is one for Bill. What's happening is that we're returning an error status in OnStopRequest, but the StreamXferOp code isn't noticing it and Stopping the transfer. This causes me to hang on Windows. After stopping, we need to put up a dialog describing the error, but necko doesn't provide the error message yet. For beta, I propose to put in the following patch, and then add the error dialog and message later: Index: nsStreamXferOp.cpp =================================================================== RCS file: /cvsroot/mozilla/xpfe/components/xfer/src/nsStreamXferOp.cpp,v retrieving revision 1.22 diff -c -r1.22 nsStreamXferOp.cpp *** nsStreamXferOp.cpp 2000/02/04 09:29:55 1.22 --- nsStreamXferOp.cpp 2000/02/10 09:07:46 *************** *** 336,341 **** --- 337,351 ---- nsresult aStatus, const PRUnichar *aMsg ) { nsresult rv = NS_OK; + + // If an error occurred, shut down. + if ( NS_FAILED( aStatus ) ) { + this->Stop(); + + // XXX need to put up a dialog here + // The error, e.g. NS_ERROR_FILE_ACCESS_DENIED, should have + // an associated message, but necko isn't providing that yet. + } // Close the output stream. if ( mOutputStream ) {

That patch looks good. We should consider adding a call to OnError in this case, also. That will generate some sort of user notification, most likely just a JS alert with some ugly exception info. But, we can embellish that later.

I applied that patch with the addition of: this->OnError( kOpAsyncWrite, aStatus ); And it produces a not-too ugly Alert with "Unknown error". That probably suffices for Beta 1. I'll check it in later today.

Fix checked in.

Filed bug 27609 for the alert not being very informative. Verified on Linux build 2000.02.13.08.

if one now tries to save to a dir where one hasn't write-permission, the browser will crash after that "unknown error" message. 100% repeatable it seems. Linux build ID 2000-071221

Check out bug 45629 for a related bug that is just reported.