Closed Bug 129852 Opened 22 years ago Closed 22 years ago

when saving inline image with right context menu, should suggest correct filename

Categories

(SeaMonkey :: MailNews: Message Display, defect, P2)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: Bienvenu, Assigned: Bienvenu)

References

Details

(Keywords: regression)

Attachments

(1 file)

proposed fix
1.02 KB, patch
bugzilla
: review+
sspitzer
: superreview+
scc
: approval+
Details | Diff | Splinter Review 
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.
Keywords: nsbeta1
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
QA Contact: esther → trix
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.
Attached patch proposed fix — — Splinter Review 
fix is to append &filename=name to url
Thanks to JF for all the help, cc'ing him for r=.
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
Closed: 22 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
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: