Invoke Browser Visit www.comdex.com It will invoke a "Plugin Downloader" box. Click on "Ok" button It will invoke a new windows pointing to macromedia site. Cancel the "Plugin Downloader" dialog box. Click on the "Download" icon on the macromedia site (for dowloading Shockwave Plugin). It will invoke a popup prompting for "Save or Open" of Plugin Choose Save Click "OK" This will invoke a File choose dialog box. Save it. Check the dir. where it should have saved the file. You wont find it Go to /tmp and you will find the file there. Looks like it saves in '/tmp' dir. regardless of the path specified. Tried it on Solaris 2.7 (sparc). The following was used for this build: 1106 Commercial Build [tag: -r Netscape_20000922_BRANCH -D "10/26/2000 10:00:00" mozilla source patch: 57725.diffs PSM: 1.3 & NSS 3.1 (NSS_3_1_RTM tag) PSM jedimind trick: libpsmshim.so Cool/AIM: sparc drop 08282000 ,intel drop 10092000 ns source patch for run-mozilla.sh ] 1106 Commercial Blackwood Build [tag: -r JAVADEV_PR3_20001002 ] 1024 Commercial Build gtk libs Java Plugin 1.3.0_01 FCS bits

Updated status whiteboard.

If you try to point ot a dir. which does not have permissions to write, then it saves into /tmp.

This bug occurs only when the user does not have write permissions on the directory he/she is trying to save (like /opt). This works ok when the write permissions exist(like in /home/<user>). I'm updating bug summary with this info.. -raghu

Reassigning to drapeau and moving to m1.0.

raju: what should the expected behavior be, please? Should the attempted save simply fail, for example?

yes, it should fail,as user is not prompted with any message indicating the destination dir. did not have permissions and also has no indication saying that the file got saved in /tmp. but the file saved in /tmp is not with its actual name, but with a temporary name. So say you were saving file flash_solaris.tar.gz in adir /opt/test which has no write permissions. It would actually save the file as <some temporary name>.gz in your /tmp dir. This should not have happened. If it was temporarily done , then it should have been removed, if permissions were denied on the destination dir.

Reproduced with 04/06/2001 nigthly under RH Linux 6.2 .

Updating the bug OS to Linux based on comments from Alexei.

add ychung to cc list

Per Yiming's request, assign this bugg to herself!

accept

Andrew/Peter, could you please review the patch? Thanks.

I don't see any immediate problems with the patch, but how this bug ended up with the Plugins component? XP Toolkit maybe?

from the problem description, it appears to be related to plugins, but the fix is on XPToolkid. Should I also ask Peter Trudelle to review the patch for me?

I think he is the right person. Adding.

It looks like it is closer to XPApps domain after second thought. cc to Don and Steve. Don/Steve, I add an error dialog when users have no write permission to save a plugin download file. Could you please review the code for me? Thanks.

Don and Steve are long gone, and I'm not the right person to review this, but bryner probably is, cc'ing him.

see also bug 27609

*** Bug 93653 has been marked as a duplicate of this bug. ***

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

bryner: Can you review this (old) patch ?

Code to fix this issue was checked in as part of the fix for bug 114399

v(stamp)