when saving inline image with right context menu, should suggest correct filename. Right now, we suggest the imap url for the message, e.g., Test%20Messages%3E1. This bug is spun-off from bug 73946 - the fix is probably in the same file as that fix, or in some method in nsImapUrl that gets the file name.
Nominating, because w/o the proper file extension, most people won't be able to open the saved file.
adding keywords. The save as feature is pretty much worthless for normal end-users without this.
Keywords: mozilla1.0, regression
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla1.0
Actually, is this really a regression? I don't remember it ever working for inline images. Did this work in .9.4 or .9.5, for example?
Status: NEW → ASSIGNED
Yes, this is a regression, I used it all the time... it stopped working when the code for "Save web page complete" landed...
Mike, do you remember roughly when that was that it was broken?
.9.6 worked, .9.7 didn't. From Bonsai, the offending code was checked in on 12/11/2001 which falls right in between those two milestones. (Apparently we don't save nightly's from that long ago.) The problem is that the code for bug 11632 went in and broke the entire "save as" mechanism for mail/news. bug 73946 is the first step in fixing that, but we no longer suggest the filename.
*** Bug 131102 has been marked as a duplicate of this bug. ***
OK, just some test cases i have found 2002031115 emails with jpg attatchments come up with no file name (fails to save, just gets stuck) opening the jpg attatchment in a new window has same problem (fails to save, just gets stuck) *.eml attachments are sugested a file name Inbox.jpg (fails to save, just gets stuck)
Thanks, Mike. I think the change is that Ben rewrote the code that figures out the file name in js, instead of using nsIStreamTransfer. I can't really tell how his code is different, but I'm going to try plugging in the old code and see if it works, and work backwards from there.
I tried an 11/22/01 build, and it did NOT suggest the correct file name. Also spent a few hours trying to build a tree pulled by date 12/01/01 and that one didn't work either. I'm still looking for hard evidence that the file name suggestion part ever worked. I'll try an older build if I can find one.
I also downloaded a .9.6 build and it did not work for my test case. So I think I'm going to proceed on the assumption that my test case, at least, never worked.
I think that must be the case... I just downloaded .9.6 and it is working fine. My testcases both involved either finding an old email with an inline image, or going to a alt.binaries newsgroup. In .9.6 they all seem to work, in .9.7 the dialog doesn't even come up...
I was doing imap - I'll try a local message.
I could not find any cases where saving inline images worked with my .9.6 build - can you point me at a newsgroup and news message that works for you in .9.6 but not on the trunk? Or attach/send me a mail message with an inline image that works in .9.6 but not the trunk? I'll copy it to a local folder and try it. Thx.
Anyone have examples of inline images that worked? Sending me E-mail is fine...my theory at the moment is that attached images worked fine (and work fine now), but inline images don't work at all.
I've found a fix for the basic problem with inline images - the fix is in libmime, and involves parsing out the filename from the mime headers in mimemrel.cpp and adding the filename to the url that layout eventually gets. Patch upcoming, once I iron out some issues with the headers generated by different mail clients.
Created attachment 75211 [details] [diff] [review] proposed fix fix is to append &filename=name to url
Thanks to JF for all the help, cc'ing him for r=.
17 years ago
Attachment #75211 - Flags: superreview+
Comment on attachment 75211 [details] [diff] [review] proposed fix please move the 2 existing comment lines above the new code down after the code you have added. Appart that, R=ducarroz
Attachment #75211 - Flags: review+
thanks, I've alread done that :-)
Comment on attachment 75211 [details] [diff] [review] proposed fix a=scc
Attachment #75211 - Flags: approval+
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
I don't know if it is this bug or 116234 (or some other bug that my query didn't uncover) that shouldn't have been closed, but saving an inline image from a news message still does not work (for me under Windows 98 at least). Sure now I can right click and select save as and get the file manager with the appropriate name in it. But when I then click to save the file nothing actually happens. The file is not saved. I get the file transfer progress window considering I am testing with rather small files and shoud only be moving the file from the cache to the saved directory I am surprised this appears, the progress bar is either completely filled or completely empty so I check "do not show again" click on the close button. Future attempts to save files now silently fail. I think the file is being saved because I clciked on save, there is no error message, etc. If I now delete the message I was saving the attachment from I will lose the attachment altogether -- thus this is a data loss bug. I can work around by saving from the attachments list -- which still has the bug of not saving from cache but downloading the attachment again -- but then the appearance of save as in the right-click dialog simply is misleading.
E Hays, do you have the message downloaded for offline use and are you offline? I think that doesn't work, saving images in messages that have been downloaded for offline use while offline. Other than that, it works fine for me.
No, I'm not offline. But I have discovered that this is intermitent (typical). One time I try to save the inline it works, pulls it out of the cache. But another time if I try to save the image it tries to download the attachment again and stalls at 0 downloaded. I can dismiss the download progress window and continue to use mail, but I can not save this inline image now unless I use the attachments pane. My mail service makes me periodically resubmit my login and password (maybe when I start another simultaneous connection?) and I was wondering if, when save as fails to draw from the cache maybe it opened another connection and then failed to open the dialog for login and password and so stalled. Just a random theory. So less severe than I originally thought but still potentially a problem worth taking note of. I'll try to find a reliable way to reproduce this, but it may be newserver dependent.
Sorry for the followup to my own post, but after more tries it seems to me this always fails on the second try, until I use the attachment pane after which it always can save from then on. 1. First save works, 2. second save (overwriting first save) fails. 3. More tries continue to fail. 4. Use attachment pane and overwrite works. 5. Now right-click saving works 6. and can overwrite every time. Or else I can right-lcick save once, then save using the attachment pane, then righ-click save as many times as I want. I know using the attachment pane causes the image to download a second time and wonder if this has somehting to do with the later successes with right-click saving.
I can confirm that on my release Gecko/20020329 on linux this works OK
I upgraded to 2002040503 (Windows 98) and I am still having intermittent problems with saving inline images from news. I can't believe I am the only one. Sometimes it saves, sometimes I get the download progress dialog and no progress shows, sometimes I don't get the progress dialog and so think the file has saved, but when I look in the directory where I saved the file it isn't there. Personally, I don't care about this feature, but I think it is problematic to include an only semi-functional feature that can result in data loss in a 1.0 release (if I save an attached inline image, think it has saved and the news article expires before I notice it didn't really save, I have lost the data).
Everything is working fine for me now... I have no problems with the file name or actual save. E Hays, I'd recommend that you file a new bug as opposed to reopening this one. You will get a better chance at finding someone to Confirm and reproduce it if you do that....
verified on trunk 2002042510
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.