Closed Bug 116234 Opened 23 years ago Closed 22 years ago

can't save mail or news image attachments with right click menu

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: f300v10, Assigned: Bienvenu)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: When fixed, mark 73946 fixed as well)

Attachments

(1 file)

proposed fix
1.26 KB, patch
law
: review+
darin.moz
: superreview+
dbaron
: approval+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20011220
BuildID:    2001122006

Right clicking on an image attached in mail or news brings up a menu with a Save
Image option.  That option stopped working on Linux builds as of build
2001121208. Selecting that option does nothing.  The 2001121108 build is the
last one that functions correctly.  

Right clicking on the 'Attachments:' window Save As still works.  However right
clicking on the news image itself saved the image from the cache, while saving
from the Attachments menu causes the news article to be downloaded again when
saving.  This is a pain for people on slow connections.


Reproducible: Always
Steps to Reproduce:
1.Read a news article with an image attachment
2 [details] [diff] [review].For an example go to netscape.public.mozilla.performance
3.Open one of John Morrisons Load time test results messages and right click on
the attached graph.  Then click Save Image.


Actual Results:  Nothing happens.

Expected Results:  File save dialog should appear, and the image should be saved
from the cache.

Mail attachements show the same problem.
To front end.
Assignee: mscott → sspitzer
Status: UNCONFIRMED → NEW
Component: Networking - General → Mail Window Front End
Ever confirmed: true
QA Contact: huang → esther
This bug also exists in the Windows build, exactly as described (Windows
version: XP).
OS to all based on Heiko's comments
OS: Linux → All
I have this problem too on my Windows build (Windows 98). I haven't seen this
behavoir in any other milestone releases until 0.97. The problem still exists in
the 2001122208 build I'm running right now.
Looking at bonsai, the only thing I can see that could have caused this was the
checkin for "save document with images etc." but thats still iffy.

I just noticed this problem myself. It is a real hassle for people on slow
connections because of bug 46233. 

before we release 1.0, we need to either get this working or remove the menu
item. (I'd prefer the former....)
Keywords: mozilla1.0, regression
*** Bug 116532 has been marked as a duplicate of this bug. ***
this is also broken on NT, build 2001122106

NOTE THAT THERE ARE 2 ERRORS!:

 1) there is no save-as for the image
 2) save image does not work!
Editing for grammar.

Old Summary: cant save mail or news image attachments with right click menu

New Summary: can't save mail or news image attachments with right click menu
Summary: cant save mail or news image attachments with right click menu → can't save mail or news image attachments with right click menu
I get this exception:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIWebBrowserPersist.saveURI]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://communicator/content/contentAreaUtils.js :: nsHeaderSniffer :: line
229"  data: no]

I'm not sure that this is a mail bug.
Status: NEW → ASSIGNED
Keywords: nsbeta1
reassigning to cavin.
Assignee: sspitzer → cavin
Status: ASSIGNED → NEW
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.9
Is it a dup of bug 73946?
Additional note,  when using the attachment icon of the expanded header to
save-as, the file appears to be re-pulled from the news server, rather than
written from  from  the cache (I sniffed the packets & found the same file was
requested multiple times)  - may or may-not be related to "no file save-as" bug
Cavin,

This does indeed appear to be the same as bug 73946.  But what I don't
understand is this was working for several (at least 3 perhaps more) months up
through build 2001121108.  Bug 73946 was opened on 2001-03-29 and shows no
change in status since then.  Marking this bug as a dup of 73946 would make it
appear as if this has been broken since at least March 2001, when it really was
working and then regressed on or around 12-12-2001.
in reference to comment #12. That is bug 46233

This is not a duplicate of bug 73946. That bug was fixed a while ago, and dealt
with the fact that after you clicked "save" in the dialog, the file was not
saved properly. 

This bug is about the fact that clicking on "save image as" doesn't even bring
up the dialog. 

While 73946 should have been marked fixed, it wasn't and can't be until this bug
is fixed. If we were to mark the bugs as dups, we would really be confusing
people by morphing mistakenly open bugs. 

Lets fix this bug and then mark both as fixed. 

Since this appears to have happened right when the new code to save pages and
URIs was checked in, and since the exceptions referenced in comment #9 deal with
the changes made with that code, adding ben goodger to the CC list.
Whiteboard: When fixed, mark 73946 fixed as well
QA Contact: esther → trix
there's an initial assertion, but I think that's a wild goose.  browser has the 
same assertion.  (we should log a seperate bug on that.)  my guess is it 
because the file isn't created yet, so doing IsDirectory() is failing.

NTDLL! 77f9f9df()
nsDebug::Assertion(const char * 0x01c2a014, const char * 0x01c2a000, const char 
* 0x01c29fc4, int 83) line 290 + 13 bytes
nsIOService::GetURLSpecFromFile(nsIOService * const 0x00509ef0, nsIFile * 
0x077ace30, char * * 0x077ac2c0) line 83 + 36 bytes
nsIOService::NewFileURI(nsIOService * const 0x00509ef0, nsIFile * 0x077ace30, 
nsIURI * * 0x0012c6e4) line 757 + 40 bytes
NS_NewFileURI(nsIURI * * 0x0012c6e4, nsIFile * 0x077ace30, nsIIOService * 
0x00509ef0) line 127 + 20 bytes
nsWebBrowserPersist::GetValidURIFromObject(nsISupports * 0x077ace30, nsIURI * * 
0x0012c6e4) line 540 + 20 bytes
nsWebBrowserPersist::SaveURI(nsWebBrowserPersist * const 0x077ab054, nsIURI * 
0x077ac850, nsIInputStream * 0x00000000, nsISupports * 0x077ace30) line 253 + 
39 bytes
XPTC_InvokeByIndex(nsISupports * 0x077ab054, unsigned int 9, unsigned int 3, 
nsXPTCVariant * 0x0012c888) line 106
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode 
CALL_METHOD) line 1998 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x0281de70, JSObject * 0x05e58628, unsigned int 
3, long * 0x05d38bd8, long * 0x0012cb68) line 1266 + 14 bytes
js_Invoke(JSContext * 0x0281de70, unsigned int 3, unsigned int 0) line 832 + 23 
bytes
js_Interpret(JSContext * 0x0281de70, long * 0x0012d958) line 2798 + 15 bytes
js_Invoke(JSContext * 0x0281de70, unsigned int 3, unsigned int 1) line 849 + 13 
bytes
js_Interpret(JSContext * 0x0281de70, long * 0x0012e700) line 2412 + 15 bytes
js_Invoke(JSContext * 0x0281de70, unsigned int 1, unsigned int 2) line 849 + 13 
bytes
js_InternalInvoke(JSContext * 0x0281de70, JSObject * 0x036be6a0, long 57404376, 
unsigned int 0, unsigned int 1, long * 0x0012e970, long * 0x0012e828) line 924 
+ 20 bytes
JS_CallFunctionValue(JSContext * 0x0281de70, JSObject * 0x036be6a0, long 
57404376, unsigned int 1, long * 0x0012e970, long * 0x0012e828) line 3405 + 31 
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x0281c160, void * 
0x036be6a0, void * 0x036bebd8, unsigned int 1, void * 0x0012e970, int * 
0x0012e974, int 0) line 1011 + 33 bytes
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x03ad8be0, 
nsIDOMEvent * 0x077aa368) line 180 + 77 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x03ad8b40, 
nsIDOMEvent * 0x077aa368, nsIDOMEventTarget * 0x03ae5e68, unsigned int 8, 
unsigned int 7) line 1205 + 20 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x03ad8920, 
nsIPresContext * 0x030474b0, nsEvent * 0x0012f4a4, nsIDOMEvent * * 0x0012f350, 
nsIDOMEventTarget * 0x03ae5e68, unsigned int 7, nsEventStatus * 0x0012f4f0) 
line 2195 + 36 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x03ae5e60, nsIPresContext * 
0x030474b0, nsEvent * 0x0012f4a4, nsIDOMEvent * * 0x0012f350, unsigned int 1, 
nsEventStatus * 0x0012f4f0) line 3359
PresShell::HandleDOMEventWithTarget(PresShell * const 0x030269c0, nsIContent * 
0x03ae5e60, nsEvent * 0x0012f4a4, nsEventStatus * 0x0012f4f0) line 6033 + 36 
bytes
nsMenuFrame::Execute() line 1627
nsMenuFrame::HandleEvent(nsMenuFrame * const 0x0372a288, nsIPresContext * 
0x030474b0, nsGUIEvent * 0x0012f92c, nsEventStatus * 0x0012f824) line 480
PresShell::HandleEventInternal(nsEvent * 0x0012f92c, nsIView * 0x077aaae0, 
unsigned int 1, nsEventStatus * 0x0012f824) line 6001 + 38 bytes
PresShell::HandleEvent(PresShell * const 0x030269c4, nsIView * 0x077aaae0, 
nsGUIEvent * 0x0012f92c, nsEventStatus * 0x0012f824, int 0, int & 1) line 5909 
+ 25 bytes
nsView::HandleEvent(nsView * const 0x077aaae0, nsGUIEvent * 0x0012f92c, 
unsigned int 0, nsEventStatus * 0x0012f824, int 0, int & 1) line 387
nsView::HandleEvent(nsView * const 0x077a95a0, nsGUIEvent * 0x0012f92c, 
unsigned int 0, nsEventStatus * 0x0012f824, int 0, int & 1) line 344
nsView::HandleEvent(nsView * const 0x077a9d40, nsGUIEvent * 0x0012f92c, 
unsigned int 0, nsEventStatus * 0x0012f824, int 0, int & 1) line 344
nsView::HandleEvent(nsView * const 0x03025700, nsGUIEvent * 0x0012f92c, 
unsigned int 0, nsEventStatus * 0x0012f824, int 1, int & 1) line 344
nsViewManager::DispatchEvent(nsViewManager * const 0x03025ac0, nsGUIEvent * 
0x0012f92c, nsEventStatus * 0x0012f824) line 1909
HandleEvent(nsGUIEvent * 0x0012f92c) line 83
nsWindow::DispatchEvent(nsWindow * const 0x077a9874, nsGUIEvent * 0x0012f92c, 
nsEventStatus & nsEventStatus_eIgnore) line 850 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f92c) line 871
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 4527 
+ 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 
4779
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 5767225, long * 
0x0012fd20) line 3419 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x00100448, unsigned int 514, unsigned int 0, 
long 5767225) line 1115 + 27 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
nsAppShellService::Run(nsAppShellService * const 0x004b4da0) line 303
main1(int 2, char * * 0x00444b90, nsISupports * 0x00000000) line 1285 + 32 bytes
main(int 2, char * * 0x0044

the real problem is that this fails:

line 3325, nsImapService:

nsCOMPtr<nsIImapUrl> imapUrl = do_QueryInterface(aURI, &rv);

here's the stack:

nsImapService::NewChannel(nsImapService * const 0x041deb6c, nsIURI * 
0x077a3870, nsIChannel * * 0x0012c5ec) line 3326
nsIOService::NewChannelFromURI(nsIOService * const 0x00509ef0, nsIURI * 
0x077a3870, nsIChannel * * 0x0012c5ec) line 794 + 31 bytes
NS_OpenURI(nsIChannel * * 0x0012c69c, nsIURI * 0x077a3870, nsIIOService * 
0x00509ef0, nsILoadGroup * 0x00000000, nsIInterfaceRequestor * 0x077a2550, 
unsigned int 0) line 148 + 20 bytes
nsWebBrowserPersist::SaveURIInternal(nsIURI * 0x077a3870, nsIInputStream * 
0x00000000, nsIURI * 0x077a3140, int 0) line 640 + 45 bytes
nsWebBrowserPersist::SaveURI(nsWebBrowserPersist * const 0x077a2554, nsIURI * 
0x077a3870, nsIInputStream * 0x00000000, nsISupports * 0x077a3ea0) line 256 + 
30 bytes
XPTC_InvokeByIndex(nsISupports * 0x077a2554, unsigned int 9, unsigned int 3, 
nsXPTCVariant * 0x0012c888) line 106
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode 
CALL_METHOD) line 1998 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x0281de70, JSObject * 0x05e57f88, unsigned int 
3, long * 0x05d38bd8, long * 0x0012cb68) line 1266 + 14 bytes
js_Invoke(JSContext * 0x0281de70, unsigned int 3, unsigned int 0) line 832 + 23 
bytes
js_Interpret(JSContext * 0x0281de70, long * 0x0012d958) line 2798 + 15 bytes
js_Invoke(JSContext * 0x0281de70, unsigned int 3, unsigned int 1) line 849 + 13 
bytes
js_Interpret(JSContext * 0x0281de70, long * 0x0012e700) line 2412 + 15 bytes
js_Invoke(JSContext * 0x0281de70, unsigned int 1, unsigned int 2) line 849 + 13 
bytes
js_InternalInvoke(JSContext * 0x0281de70, JSObject * 0x036be6a0, long 57404376, 
unsigned int 0, unsigned int 1, long * 0x0012e970, long * 0x0012e828) line 924 
+ 20 bytes
JS_CallFunctionValue(JSContext * 0x0281de70, JSObject * 0x036be6a0, long 
57404376, unsigned int 1, long * 0x0012e970, long * 0x0012e828) line 3405 + 31 
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x0281c160, void * 
0x036be6a0, void * 0x036bebd8, unsigned int 1, void * 0x0012e970, int * 
0x0012e974, int 0) line 1011 + 33 bytes
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x03ad8be0, 
nsIDOMEvent * 0x077a14f8) line 180 + 77 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x03ad8b40, 
nsIDOMEvent * 0x077a14f8, nsIDOMEventTarget * 0x03ae5e68, unsigned int 8, 
unsigned int 7) line 1205 + 20 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x03ad8920, 
nsIPresContext * 0x030474b0, nsEvent * 0x0012f4a4, nsIDOMEvent * * 0x0012f350, 
nsIDOMEventTarget * 0x03ae5e68, unsigned int 7, nsEventStatus * 0x0012f4f0) 
line 2195 + 36 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x03ae5e60, nsIPresContext * 
0x030474b0, nsEvent * 0x0012f4a4, nsIDOMEvent * * 0x0012f350, unsigned int 1, 
nsEventStatus * 0x0012f4f0) line 3359
PresShell::HandleDOMEventWithTarget(PresShell * const 0x030269c0, nsIContent * 
0x03ae5e60, nsEvent * 0x0012f4a4, nsEventStatus * 0x0012f4f0) line 6033 + 36 
bytes
nsMenuFrame::Execute() line 1627
nsMenuFrame::HandleEvent(nsMenuFrame * const 0x060f8a00, nsIPresContext * 
0x030474b0, nsGUIEvent * 0x0012f92c, nsEventStatus * 0x0012f824) line 480
PresShell::HandleEventInternal(nsEvent * 0x0012f92c, nsIView * 0x077a1770, 
unsigned int 1, nsEventStatus * 0x0012f824) line 6001 + 38 bytes
PresShell::HandleEvent(PresShell * const 0x030269c4, nsIView * 0x077a1770, 
nsGUIEvent * 0x0012f92c, nsEventStatus * 0x0012f824, int 0, int & 1) line 5909 
+ 25 bytes
nsView::HandleEvent(nsView * const 0x077a1770, nsGUIEvent * 0x0012f92c, 
unsigned int 0, nsEventStatus * 0x0012f824, int 0, int & 1) line 387
nsView::HandleEvent(nsView * const 0x077a0260, nsGUIEvent * 0x0012f92c, 
unsigned int 0, nsEventStatus * 0x0012f824, int 0, int & 1) line 344
nsView::HandleEvent(nsView * const 0x077a0950, nsGUIEvent * 0x0012f92c, 
unsigned int 0, nsEventStatus * 0x0012f824, int 0, int & 1) line 344
nsView::HandleEvent(nsView * const 0x03025700, nsGUIEvent * 0x0012f92c, 
unsigned int 0, nsEventStatus * 0x0012f824, int 1, int & 1) line 344
nsViewManager::DispatchEvent(nsViewManager * const 0x03025ac0, nsGUIEvent * 
0x0012f92c, nsEventStatus * 0x0012f824) line 1909
HandleEvent(nsGUIEvent * 0x0012f92c) line 83
nsWindow::DispatchEvent(nsWindow * const 0x077a0534, nsGUIEvent * 0x0012f92c, 
nsEventStatus & nsEventStatus_eIgnore) line 850 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f92c) line 871
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 4527 
+ 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 
4779
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 6225995, long * 
0x0012fd20) line 3419 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x000f0448, unsigned int 514, unsigned int 0, 
long 6225995) line 1115 + 27 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
nsAppShellService::Run(nsAppShellService * const 0x004b4da0) line 303
main1(int 2, char * * 0x00444b90, nsISupports * 0x00000000) line 1285 + 32 bytes
main(int 2, char * * 0x00444b90) line 1625 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87903()

the reason is it failing is that aURI is a nsIFileURL, but the spec is:

"imap://sspitzer@nsmail-1:143/fetch%3EUID%3E/INBOX%
3E108808part=1.2&type=image/gif&filename=kerz.mcom.com/1.gif"


I'm not sure it matters yet,

but this works for HTTP.

in nsIOService::NewChannelFromURI()
   
    nsCOMPtr<nsIProxiedProtocolHandler> pph = do_QueryInterface(handler);
    if (pph)
        rv = pph->NewProxiedChannel(aURI, pi, result); // we get here for http
    else
        rv = handler->NewChannel(aURI, result);  // we get here for imap

does the nsIFileURL / scheme issue work for http, because it implements 
nsIProxiedProtocolHandler?
I might be adding to the confusion, not helping.

backing up a step, in nsHeaderSniffer() in contentAreaUtils.js we do this:

  const stdURLContractID = "@mozilla.org/network/standard-url;1";
  const stdURLIID = Components.interfaces.nsIURI;
  this.uri = Components.classes[stdURLContractID].createInstance(stdURLIID);
  this.uri.spec = aURL;
  
  this.mPersist.saveURI(this.uri, null, this.mTempFile);

maybe we're creating the wrong thing and passing it in?
This is where NS_ERROR_FAILURE comes from...

/* void saveURI (in nsIURI aURI, in string aFileName); */
NS_IMETHODIMP nsWebBrowserPersist::SaveURI(
    nsIURI *aURI, nsIInputStream *aPostData, nsISupports *aFile)
{
    NS_ENSURE_TRUE(mFirstAndOnlyUse, NS_ERROR_FAILURE);
    mFirstAndOnlyUse = PR_FALSE; // Stop people from reusing this object!

....
seth: nsIProxiedProtocolHandler shouldn't have much to do with this i hope ;)
I can confirm this bug's exisitence in both Mozilla releases 0.9.7 and 0.9.8
on Mac OS X 10.1.2 , with build 2002020411, the save image contextual menu does
nothing (the save as... in the attachment windows does nothing either)

On Mac Os 9.1, with the same build 2002020411, the save image contextual menu
crashes Mozilla. (the save as... in attachment window works)

With build 2002021413 and MacosX, the correct file name appears in the menu.
after select, a saved box appears, but with a weird name by default
(e.g:6Q1b8.13552$X2.157323@nnrp1.uunet.ca). Once i click save without changing
name, the box closes but nothing is saved. if i change the name to the real one,
a folder with this name and _files appended is created but no image.
Additionnaly, the save as in the attachment window is desactivated.

The build 2002021413 for MacOS 9.1 has the same behaviour as on Mac OS X version
for the Save Image item from right-clicking on the image but does not crashes
anymore
(and the save as in attachment window still works like a charm)

Hope this help 
(i mainly use MacOS X)
by the way, The bug seems to be cross-platform and multi-OS

New behavior of the Windows version, build 2002021203: when I right-click on an
image attachment, the context menu displays the correct filename (example: "Save
Image (image.jpg)"). After clicking on this menu option, a "Save Picture" window
opens, just like it should. But the file name is replaced by a weird default
name which is identical to the message-ID in the header. Saving this actually
creates an empty folder with the name "<message-ID>_files" (where <message_ID>
of course stands for the message-ID).

After reading Rija's comments, I also experimented with saving the file under a
different name. Every time, a new empty folder is created. When I specified
"image" as the file name, assuming that Windows would add the ".jpg" extension
based on the chosen file type as usual, the folder's name turned out to be
"_files". When I added the extension myself, so the file name would be
"image.jpg", the resulting folder was named "image_files".

Using Windows XP, the bug's behavior seems to be essentially the same but
slightly different from Rija's observations using MacOS. Maybe that is because
of OS differences? I don't exactly recognise what Rija calls "Attachment
window", but I assume that it's function is similar to the Attachment menu
option in the Windows version. This is still working the same as before.
Moving to moizlla1.0.
Target Milestone: mozilla0.9.9 → mozilla1.0
*** Bug 120894 has been marked as a duplicate of this bug. ***
*** Bug 126383 has been marked as a duplicate of this bug. ***
taking
Assignee: cavin → bienvenu
the basic problem here is that the uri passed to NS_NewChannel is just an
nsIStandardUrl and not the correct kind of url (e.g., an nsImapUrl) for the
channel, so all the mail protocol handlers barf right away.
Attached patch proposed fix — — Splinter Review 
instead of creating a standard uri, use the io service to create the right kind
of uri.
cc'ing law, who cvsblame points at for the code I changed. Please let me know if
this change seems ok.
Status: NEW → ASSIGNED
Comment on attachment 73323 [details] [diff] [review]
proposed fix

sr=darin
Attachment #73323 - Flags: superreview+
thanks, Darin. Can I get an r= from someone resembling a module owner for this
code? thx.
Comment on attachment 73323 [details] [diff] [review]
proposed fix

r=law
Attachment #73323 - Flags: review+
cc:ing Ben and Boris 'cause they've worked on this code recently, too
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
The right click save image asks now for a file name and thus is an image save
possible. There is one minor thing left. The file name used is incorrect. The
image I tested was called 007.jpeg the save as filename was Inbox.jpeg,

This was on Linux build :

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020309
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
That's being handled under bug 129852
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
OK then this bug is solved. Will vote for other bug as suggested
*** Bug 129949 has been marked as a duplicate of this bug. ***
*** Bug 130172 has been marked as a duplicate of this bug. ***
*** Bug 131701 has been marked as a duplicate of this bug. ***
verified on trunk 2002040908
Status: RESOLVED → VERIFIED
*** Bug 144369 has been marked as a duplicate of this bug. ***
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: