scenario: mozilla news client up and running, fetching articles from appropriate server etc. but, as far as saveing any images is concerned, it is broken. right clicking an image provides a menu, with menu item "Save Image As". selecting this menu item pops up a save dialog for the image, with a "BOGUS" suggested image name of this kinda sort "blahblah.blah@blahhost.org". attempts at saveing this as a file results in the above filename being saved as plain News Text. thanx for the time. -Az

WORKSFORME using 2000121808, Redhat 7, using server news.netscape.com.

VERIFIED WFM.

compiled appropriate mozilla source from cvs 2000121808 snapshot, on Debian GNU (woody) Linux box: gcc version 2.95.2 libc 2.2-5 kernel 2.4.0-test10 nntp server running leafnode 1.9.18 works fine with communicator 4.76, allways has, does not work for mozilla or netscape 6, tried them both, same effect. allso, tested on a completely different Debian Linux box, same thing happens. since i believe this to be a feature wich i need to have, i can't switch to mozilla until this is fixed. please clue me in on what i can do to provide assistance into aiding the resolution of this problem.

I don't think it's healthy for an unconfirmed bug to have a set milestone. Especially mozilla0.6 which is now history. Clearing milestone field.

Reporter have you tried removing your profile and reinstalling Mozilla?

Azreal, if you could grab an installer build from ftp://ftp.mozilla.org/pub/mozilla/nightly/2000-12-28-08-Mtrunk/ that would really help a lot.

tried removeing profile twice. downloaded reccomended nightly build (2000-12-28-08-Mtrunk). removed old profiles, etc. re-installed, same problem continues. more specifically, i have dicovered the file is trying to be saved as the message ID, which if i open the file being saved and look at the first line of plain old uuencode, it is the (Message-ID: <3a3dd721_7@mach4news.aaria.net.nz>) which appears in the "Save Image As" dialog. so, instead of, for instance "blah.jpg" i would have "3a3dd721_7@mach4news.aaria.net.nz" furthermore, this could be confuseing post-processing of the said image, or seems to be. thanx for your time.

Marking NEW as per comments.

Really marking NEW.

for bug 21515, i'm adding the image name to the context menu. On linux, it is inbox?number=blabla. adding myself to cc

what is the status on this bug? is anyone working on it, or even able to reproduce it as described by me? I surely cannot be the only one who is haveing this problem. i have been watching for info, but nothing is happening. no changes made, etc. it would be kool for me to start useing mozilla, in place of communicator for my current needs.

what is the status on this bug? is anyone working on it, or even able to reproduce it as described by me? I surely cannot be the only one who is haveing this problem. i have been watching for info, but nothing is happening. no changes made, etc. it would be kool for me to start useing mozilla, in place of communicator for my current needs.

reporter: please set the url field for the bug to the message where you reproduce this failure. ie. I should be able to click the url and have it load in messenger. Otherwise it's hard for us to honestly test, reproduce, triage, reduce and fix.

The only thing I experience with this on linux is that we salt the filename when you do a Save As, it comes out like this in mail/news: "INBOX>444". We actually do save (at least on my machine) the filename correctly, but salting was something our developers did to increase security.

please take a moment to look at my post to: server = news.mozilla.org newsgroup = netscape.test find my message, read it, refer back to the beginning of this bug, you will notice what im talking about. im sorry, i do not know how to include a news document as a URL, if you know how, then please do it with my example article. thanx gang

once again i note, the image name being offered is the Message-ID, not the name of the image, whats with that? that should provide some clue at least, im not a programmer, so i do not follow, please have mercy on me! :)

lets try this url for a bit [nc4 lets you drag a news posting to an edit box and get a news url, very convenient]. the image url is http://www.oldiesonlinecasino.com/img/25perbonus.gif please tell us what you see. Of course, this isn't an appropriate posting, but finding appropriate postings that include graphics is painful. I'm 99% sure the article you mentioned expired already :-(

this is not the correct way to reproduce this bug. opening this as a URL does not bring up the same interface, as does a browseing a local or remote news server, subscribeing to any given newsgroup, and saveing images to disk. saveing images from a web page works just fine, as it should. so, 1.) add a news server, for me "leafnode" 127.0.0.1 2.) get a list of groups, 3.) subscribe to one. any will do, most groups at least have some spam with some lame image included. 4.) browse messages, find a post with included attachment, "uuencoded jpeg" for example, news browser filters and displays as image coorectly, all is well... 5.) now try right clicking on the same image to save to disk. 6.) if this does not reproduce this bug, then i may as well throw in the towel :P because, at least for me, and 2 other computers i tried it on, doesnt work...

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

I'm seeing this also in Mail. (Mozilla/2001021609 Linux) I got a pop3 mail with an image as attachment, trying to save the image via right click on it and selecting save image, resulted in filename 'Inbox' (see bug 58596) and a saved file that contains the whole message (what I would expect to be a .eml file or something like that). When I openend the attachment by clicking on the attachment entry in the popup (or File > Attachment) and saved it from navigator, I got the same. Then I tried to open that saved file (I remaned it to .eml extension) in Mozilla 0.8 and Netscape 6 on Windows 98 (!) and tried to save the image out of there (right-click again), both both saved the full message instead of the image. Only NS6 showed me the image only when I selected "Show Image", and I could save it from there finally. As the last paragraph showed up this bug in win32, setting to OS=all. If you want the message file (118K), I can can attach it or mail it to anyone who wants to try.

I also see this bug as described, "Save Image" saves the article, headers and all, and not the specific image. The suggested filename is the message-id, and not the image filename. This is with build 2001021904. This was broken in the past month.

removing milestone and nominating for nsbeta1

I'm going to mark bug 58596 as duplicate of this. There are actually a few similar bugs flying around out there. When QA verifies this bug, we'll verify against images in both mail messages and news postings. Side note: Command to Save Image as or View Image seems to be completely blown away in current commercial trunk builds to where you can't even get to this bug's point. I'll log a new bug for the "more broken" condition if I don't see one.

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

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

marking nsbeta1+ and moving to mozilla0.9

moving to mozilla0.9.1

Same bug on BeOS, build 2001021912. A bit limiting... ,-)

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

This bug is actually when *inline* attachments (jpg's) are received - mail, newsgroups, etc. Therefore, the summary must be changed to reflect this. Please change the summary to: View/Save context menu on inline attachments saves entire message and not the file. Also, please add the keywords: *nscatfood* and *helpwanted* (as I cannot do it)

oops, looking at the CC list, we should probably also add the keyword: *mostfreq*

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

This bug is currently scheduled for 0.9.1, so I don't think we need to add helpwanted. If that changes, we can add it. Likewise, marking the bug catfood won't change when the bug actually gets done given that it's already scheduled.

Note with builds 2001-04-17 on winme, mac and linux current results: Mac will save the file as "Inbox>108782" to my desktop. However, when opening that file name in Browser it shows garbage. If I change the name during the save or after the save to test.jpg the .jpg file opens OK. Linux will save the file as "Inbox>108782" to my desktop. Doesn't recognize it to allow me to open it in Bowser. If I change the name during the save or after the save to test.jpg the .jpg file opens OK. WinME doesn't allow me to save it with the bogus name (as stated in this bug). but if I change the name during save to test1.jpg the file saves and is OK when viewed in Browser.

reassigning to cavin

reading a news message with an image: I right clicked on the image to save save it. I saved it as "3AE6171F.7070502@netscape.com". I was able to rename it and view it. alternatively I was able to save it as foo.jpg and view it. reporter, at one time you had a particular message to netscape.test that would exhibit the "saves as plain text" problem. can you post it again?

if I go through the "attachment icon" in the message pane to save the attachment, we do the right thing. if I go through "file | attachments", I crash. (I'll go log that bug now.) reporter, can you post the message to netscape.test again that makes it so we save as plain text?

The real problem is now I think of what it looks like when you are right-clicking an image, vs using the attachment button: Using the attachment button: gateway.jpg Using the context menu on the image itself: 3ABC48CF.50000605@netscape.com Shouldn't this bug's scope be changed to reflect the fact that we should be using, on a context-click of any attachment, the same name of the image (gateway.jpg), instead of forcing the user to rename this image (and wondering about all the path info in the Save File dialog)?

I just spoke with Cavin. Here is another scenario: Open a mail message with a .jpg attachment Use the Open option on the attachment button -this will open the .jpg in a Browser window. Use File|Save As from the Browser window. You get a bogus file name. Test this scenario too

Good job. R=ducarroz. BTW, did you figure out why was the "&hackID" for? Anyway, it wasn't used!

Seth asked me to try gif filenames with non-ascii chars in them and the fix did not work. It also failed on the filename like '&foo.gif' becaused the special char '&' is not escaped (as %26). The '&filename=' parameter in the image url needs to be (encoded) in escaped UTF-8. Will submit another patch when this is fixed. Good catch, Seth.

The patch only addresses the issue of filenames like '&foo.gif'. Seth will log another bug regarding the non-ascii chars in the attachment filenames. Right now, if you try to save the image (ie, right mouse click on Save Image) the (non-ascii) filename does not show up in the Save File dialog at all.

filenames with "brackets" are not working - database(abc).mdb becomes database%28abc%29.mdb

peter, did you try that with cavin's latest patch?

seems to be working on 2001-05-09

The patch only addresses the issue of filenames like '&foo.gif'. Seth will log another bug regarding the non-ascii chars in the attachment filenames. Right now, if you try to save the image (ie, right mouse click on Save Image) the (non-ascii) filename does not show up in the Save File dialog at all.

I would like to see an alternative when escape failed, just in case. Something like: if (filename) { url_with_filename += "&filename="; char *escapedName = nsEscape(filename, url_Path); if (escapedName) { url_with_filename += escapedName; nsCRT::free(escapedName); } else url_with_filename += filename; } If you do that, R=ducarroz

JF, there is a problem with your idea because the unescaped chars may confuse parsers of the url a bit. For example, if the filename is '&foo.gif' and nsEscape() fails we'll end up having an url like the following (the line is too long so is broken into two): imap://xx@yy.com:143/fetch>UID>INBOX>12 ?part=1.2&type=image/gif&filename=&foo.gif The last '&' (ie, the one in front of foo.gif) may make a parser thinking that 'filename' attribute has no value if this particular parser relies on '&' for getting the next parameter/attribute. So when nsEscape() fails it's better not to have &filename=&foo.gif in the url (it should really be &filename=%26foo.gif).

nsEscape() should only will null if we run out of memory. [you should double check that.] in that case, you should assert and return with NS_ERROR_OUT_OF_MEMORY;

ok, ignore my comment. R=ducarroz

OK, I'll return NS_ERROR_OUT_OF_MEMORY in this case.

Waiting for mscott's review before posting another patch.

nice patch Cavin. It looks good to me. sr=mscott. B4 you check in can you try opening and saving attachments for news, imap and local to make sure we didn't damage any functionality there? Those code paths are sometimes fragile with regards to the structure of the url strings. Also, I like how you removed the bogus hackID field that mime was generating that we never used. I never could figure out what that was supposed to be used for.

Scott, I did try all 3 scenarios (news, imap and local) and they worked fine.

in nsMsgMailNewsUrl::SetSpec, instead of: I'd do this #define FILENAME_PART "&filename=" #define FILENAME_PART_LEN 10 and use FILENAME_PART_LEN instead of offset. and FILENAME_PART instead of "&filename=" other than that, sr=sspitzer.

sspitzer: I can't parse your comment, did mozilla eat the first part? :(

no, I forgot to add the "Instead of:" part. instead of: + int offset = nsCRT::strlen("&filename="); + start = PL_strcasestr(aSpec,"&filename=");

fixed. cavin and I found a few other (unrelated) problems while debugging this. I'll log bugs on those now.

Verified fixed (with a single remaining UI issue, that I'll log) on: Windows 2000 build 2001-05-16-08 RedHat 7.0 build 2001-05-16-06 Mac OS 9.1 build 2001-05-16-08 Criteria for verificaton of the fix: Context clicked on images and verified that they contained the correct name of the image, and that without me having to rename them, saving them kept the filename correct. Also tried newsgroups. The images I used were: frontpage-small.gif libpr0n.png MVC-178f.jpg The remaining issue which I'll log is that when we do a context click, in the menu that follows, we say: Save Image (jpeg&filename=MVC-178f.jpg). note that this doesn't affect the next Save As dialog, or the actual name of the image, so I consider it a UI bug and I'm logging that now! Great work to all, thanks for fixing this annoying bug.

I've filed bug 81295