268150 - erroneous error dialog says cannot save file because cannot change contents of temp dir

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect, P1)

Description

[Nelson Bolyard (seldom reads bugmail)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040927
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040927

When I left click on a link to a tar file, I get an error message that says:

"<temp dir>/<file name> could not be saved, because 
 you cannot change the contents of that folder.

 Change the folder properties and try again, or try saving in a different location."

where <temp dir> is my normal temp directory, and <file name> is the name 
of the tar file.  

However, if I shift-left-click on the link, and select the very same 
temp directory and file name, I have no trouble downloading the file.
There are no permission problems with my temp directory.  Whatever the 
problem really is, mozilla is misdiagnosing and misreporting it.

Note that I *do not* use the download manager.  
I use mozilla's "progress dialog" instead.  
I could not find a component that seemed appropriate for the progress
dialog, and component "download manager" seemed clearly wrong.

Reproducible: Always
Steps to Reproduce:
1. set browser to use "progress dialog" instead of download manager.
2. visit http://etud.epita.fr/~bevand_m/papers/
3. click on the link to rc4-amd64.tar.bz2  which is actually a link to 
   http://etud.epita.fr/~bevand_m/papers/rc4-amd64.tar.bz2



Actual Results:  
Progress dialog appears, and then immediately the error dialog quoted above
pops up over the progress dialog.  The progress dialog shows no indication
of any progress.

Expected Results:  
File is downloaded OK, or dialog appears that reports the real problem.

The link above downloads a file of MIME type application/x-tar
even though the name in the link ends with .bz2.  
mozilla takes the name of the file (ending in bz2) and appends .tar to it
and tries to download the file to a file of that appended name in the 
temp directory.  

The only remotely similar bug I could find in bugzilla was bug 199969.

Comment 1

[R.K.Aa.]

WFM, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041106
I get a dialog asking whether to open with default application (WinZip) etc.

Some weeks ago I frequently saw the bug you describe, but it seems to be fixed
again in recent builds. Please try a new build.

Comment 2

[Hermann Schwab]

changing version from 1.4 to Trunk, as I assume you didn´t report this bug for 
a Mozilla 1.4.x build.

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041106
I´m using the downloadmanger normally, so I´ve set the prefs according to step 1
and loaded = URL, 

Left-Click brought up a 'Enter name of file to save to...' box,
Filename: rc4-amd64.tar.bz2, File Type: *.bz2, 
and the folder suggested was the most recently used one, not temp. I´m always
selecting folders for downloads, don´t have one for all. I acknowledged,
download finished.

Right-Click, 'Open in new tab': same box as above

Right-Click 'Save Link Target As...' brought up a 'Save As' box, Folder and
suggested name as above, File Type: 'PowerArchiver BZip File' 

In Preferences->Navigator->HelperApplications I don´t have a MIME type
application/x-tar registered, but a MIME type application/x-bzip2 having
extension .bz2, and 'save file to disk' specified as action. 

Could it be that a helper application for .tar or .bz2 is trying to open the
file, but can´t write its temp file, as the inputfile already is in temp, so
blocking the name?

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

>Could it be that a helper application for .tar or .bz2 is trying to open the
>file, but can´t write its temp file, as the inputfile already is in temp, so
>blocking the name?

really unlikely, since the text of the dialog is exactly the text mozilla has
for this error code
(http://lxr.mozilla.org/seamonkey/source/embedding/components/webbrowserpersist/locale/en-US/nsWebBrowserPersist.properties#43)

Could you create an nspr log with NSPR_LOG_MODULES=HelperAppService:5?
(http://www.mozilla.org/projects/netlib/http/http-debugging.html has
instructions on how to do nspr logging)

not sure it helps, but I have really no idea how this can happen...

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Attachment: snapshot of dialogs

This problem is still reproducible with 1.8b.

In reply to comment 3, looks like the URL should be
http://lxr.mozilla.org/seamonkey/source/dom/locales/en-US/chrome/nsWebBrowserPersist.properties


I will try the steps CB suggested in the previous comment.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Attachment: mozila log files

As CB requested, I captured a log file of the event.  Upon examining it, 
I saw that the file in question was being found in the cache.  So, I 
cleared the cache and tried again with the same results (same dialog).	
The attached file contains the logs from both runs.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

hm... nelson: could you also create a logfile with
NSPR_LOG_MODULES=HelperAppService:5?

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Attachment: log with NSPR_LOG_MODULES="HelperAppService:5"

This log file was produced with 
NSPR_LOG_MODULES="HelperAppService:5"
I did two attempts, one from cache, one after flushing.  
Same results.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #4)
> In reply to comment 3, looks like the URL should be
>
http://lxr.mozilla.org/seamonkey/source/dom/locales/en-US/chrome/nsWebBrowserPersist.properties

(that file got moved between comment 3 and comment 4)

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

OK. 1.8b1 lacks some logging I added only later, but I think I know what happens...

So you have a helper application configured for application/x-tar. I presume you
have chosen "Use default application" for that. (screenshot of the progress dlg
seems to confirm that). You can check that in preferences/helper applications

It looks like ShellExecute for that file in the temp directory returns
SE_ERR_ACCESSDENIED, and exthandler does not verify that it was _saving_ that
failed, so it shows that error message also when launching failed.

In short... Does the windows default application handler for .tar files work?
What if you try to doubleclick that file in $TEMP while the error dialog is open?

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

I repeated the test, and when it displayed the error dialog, I opened windows 
explorer and looked at the tar file in the temp dir.  It was shown as being a 
"Visual Pax" file (which was as expected). I double-clicked on the tar file 
in the temp directory.  Windows displayed a dialog asking me to choose a 
program with which to run the file.  That dialog showed two "preferred" 
choices and many others. The two preferred choices were Mozilla (!) and vpax, 
the program I expected. I selected vpax, and also checked the "always use this 
choice" box.

Now, when I visit the above link, I no longer get the folder properties
complaint dialog.  Instead, it now runs the program.  

So, apparently the file type was properly registered, but something about
the program wasn't registered enough for windows to run it, and that 
confused mozilla leading to that error message.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Anyway, it would be better for mozilla to announce that it 
"Cannot launch helper application" than to complain about 
directory permissions (which are not the problem).

Are the Product and Component right for this bug?

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

I have a question about the behavior of appending .tar to the file's name,
so that the file named rc4-amd64.tar.bz2 is saved as rc4-amd64.tar.bz2.tar.
Is that added by mozilla? or the OS? 
Do we know why it is added?  
Does it solve some security problem?

In this case, that extra .tar suffix confuses the helper program, causing
it to think the file is just a .tar file, and not a bz2 compressed tar file.
Removing the extra suffix fixes that problem.  So, unless it is necessary
for security reasons, I'd prefer that the extra suffix was not added.
I can file a separate bug on that, if that's suggested.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

Mozilla ensures that the mime type matches extension... that's a security
feature, yes.

Comment 14

[Boris Zbarsky [:bzbarsky]]

The extension-changing is needed because we pick the helper we prompt the user
about based on the MIME type, while windows launches the helper based on the
file extension.  Therefore, any time we plan to execute a helper on Windows we
must ensure that the extension for the file matches the MIME type we used when
interacting with the user.

Note that the server reports this file as being of type application/x-tar and
doesn't report any Content-Encoding or Transfer-Encoding; given that we should
be using the helper for tar files and telling it that what we have is a tar file
(and NOT a bzipped tar file), since that's what the server tells us.

So that part of the behavior is correct.  We should still fix the error
reporting, though.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

Christian and Boris, thanks for the explanations.  

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

Checking in uriloader/exthandler/nsExternalHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v  <-- 
nsExternalHelperAppService.cpp
new revision: 1.286; previous revision: 1.285
done