Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130 Description: When attemtping to view a gif attachment, a window opens and then I am prompted with: "You have chosen to download a file of type: GIF/image..." What should Mozilla do? I uncheck "always ask me about this file type" I select "open with application" I am given a system browse window. I select Mozilla. another window opens and the file is displayed in the window. I am prompted on subsequent attempts to view this or other files of the same type. On a subsequent attempt to view a gif image, I: get a blank popup window Click ...Advanced select Mozilla to handle files of type image/gif. get another window with the image. subsequent attempts to view this or other gif images result in the same case. What should happen: By default, mozilla should show the image in a new window (and not open 2 windows). If Mozilla cannot handle a file type, then I should be prompted. In the case that I deselect "always ask me about this file type," I should not be prompted again. In the case that I select ...Advanced and choose an app, I should definitely not be asked again.
Is the site sending content-disposition:attachment for the file? If so, we will prompt regardless of the setting of "Don't ask me again" because the site is expecting the IE behavior in any case (just giving you a filepicker, not even the choice of opening in an app). We _should_ be disabling that checkbox in such cases, however...
I'm seeing this behaviour in 1.3b on Windows XP: The server sends Content-disposition: atachment; filename=marani-moppel-stall-klein.jpg [sic!], and I get prompted for what to do. I want the image to be simply displayed in the browser. Second bug: if I select "default application" or another application explicitly, the image is not shown at all! It is stored in WINDOWS/Temp with an extension ",jpg.jpeg".
I'm seeing this behaviour in 1.3b on Windows XP: The server sends Content-disposition: atachment; filename=marani-moppel-stall-klein.jpg [sic!], and I get prompted for what to do. I want the image to be simply displayed in the browser. Second bug: if I select "default application" or another application explicitly, the image is not shown at all! It is stored in WINDOWS/Temp with an extension ".jpg.jpeg".
Oliver, you must be using vbulletin. Mozilla's behavior there is correct except for the not opening a helper part....
It's a profile problem. The server (vBulletin 2.2.8) sends the headers HTTP/1.1 200 OK Date: Sat, 15 Feb 2003 17:15:26 GMT Server: Apache/1.3.27 (Unix) Cache-control: max-age=31536000 Content-disposition: filename=jippiiiiiieeeee.gif Expires: Sun, 15 Feb 2004 17:15:26GMT X-Powered-By: PHP/4.1.1 Set-Cookie: sessionhash=00000000000000000000000000000000; path=/ Set-Cookie: bblastvisit=1045329326; expires=Sun, 15-Feb-2004 17:15:26 GMT; path=/ Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT Content-Length: 46411 Keep-Alive: timeout=2, max=200 Connection: Keep-Alive Content-Type: image/gif With my normal work profile (several months old), I always get the "Download" Pop-up (asking for application / Save Location). With a newly created profile, the image is simply displayed (in the same or a new window, according to the mouse button pressed). This is Mozilla 1.3b (Full Install) on WinXP Prof. SP1 German.
Hm... mind attaching the prefs.js and mimeTypes.rdf from the "not working" profile to this bug? There's no way I know of to force external handling of image/gif with a profile setting... Also, is the server sending the same headers in both cases? You can log headers by doing: set NSPR_LOG_MODULES=nsHttp:5 set NSPR_LOG_FILE=c:\log.txt (or whatever file you want). Then run mozilla from the DOS window you set those variables in, load the one page in question (the logging is _very_ verbose), and attach the resulting logs (one for each profile) to this bug?
Created attachment 114599 [details] buggy and new profile, with log files The attachment is a ZIP file containing data about the buggy and a new non-buggy profile: prefs.js, mimeTypes.rdf, and the log files of looking up the URL http://www.ioff.org/attachment.php?s=&postid=999031
The log.txt for the buggy profile just shows us pulling from cache... could you possibly clear the cache and redo just that one log?
Created attachment 114604 [details] HTTP log after cleaning the cache - bug is gone (image is displayed normally) Cleaning the cache seems to have fixed the problem - sorry about reporting such a spurious problem as an error.
darin, any idea what could have gotten corrupted in a cache entry to make us display it like that? The log does not seem very helpful there... :(
cache corruption can be a tricky thing to track down. the big question is: does the problem recur? can it be easily reproduced given either time, or what not. in the past, cache corruption would occur if multiple instances of the app tried to access the same cache directory. that was fixed by the addition of a lock file in the profile directory, but older versions of mozilla and netscape do not honor the profile lock file. reporter: is it possible that you used an older version of netscape while you were using mozilla? running any instance of netscape 6.x while running mozilla with the same profile would cause cache corruption.
A suggestion: until a day or so earlier, the server sent Content-disposition: atachment; filename=jippiiiiiieeeee.gif for the same URL (see Comment #3); perhaps the "Content-disposition: atachment" was stored in the cache? It might have caused the download prompt, even though the server did not send the "Content-disposition: atachment" any more a day later.
Oh, right. That would certainly do it...
In my case, clearing the cache (and I looked in the cache folder to make sure it was empty) had no effect on the problem. It started when I moved from 1.2.1 to 1.3b. I still get prompted. I have not (yet) tried creating a new profile, or logging. Will try that as time permits.
Alan, in your case the site is likely sending the header mentioned earlier in this bug. Marking invalid, since the behavior that was happening was correct and there was no cache bug as far as we can tell....
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.