Closed Bug 334544 Opened 16 years ago Closed 15 years ago

'Save image' does nothing

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 333607

People

(Reporter: wa1ter, Assigned: mscott)

References

Details

(Keywords: regression)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060418 Firefox/3.0a1
Build Identifier: Thunderbird trunk nightly build

When viewing a jpeg image in the mail/news preview pane, try right-clicking on
the image and select 'Save Image'.  This should pop up the 'Save Attachment'
dialog, but in fact does nothing at all.

However, when I go thru the File/Attachments menu, all works as expected.

Reproducible: Always
Confirmed. Same error here: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060418 Thunderbird/3.0a1 ID:2006041806
Also on version 3 alpha 1 (20060418) Windows XP
OS: Linux → All
Version: unspecified → Trunk
This is true for image attachments shown inline, and for images embedded in an HTML message.  Also seen in 2a1-0416.  Works as expected in TB 1.5.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Are there any relevant JS exceptions?
xref bug 328586.  From bug 328586 comment 0:
"it would appear that Save Image also does nothing, but there's already a
bugzilla report for that."  But I couldn't find an earlier report.
*** Bug 306972 has been marked as a duplicate of this bug. ***
When "Save Image" is selected, the following error crops up (2a1-0518):

Error: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: chrome://communicator/content/contentAreaUtils.js :: poseFilePicker :: line 517"  data: no]
Flags: blocking-thunderbird2?
*** Bug 347343 has been marked as a duplicate of this bug. ***
Right now we're using xpfe's contextAreaUtils.js to handle this. We probably need to be using toolkit's since we use toolkit's downloads manager.

We'd probably need to add it to mail-jar.mn somewhere, but I feel we could get into trouble with just plopping one file from toolkit in with all the xpfe stuff.
Assignee: mscott → ispiked
Still broken on my version 3 alpha 1 (20060822) on Windows XP, I get the following error in the console:

Error: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: chrome://communicator/content/contentAreaUtils.js :: poseFilePicker :: line 518"  data: no]

I get this error on embedded and inline images when clicking "Save as" on the context menu, the Save as dialog never opens.

Hugs,
Fluffy oxo
A simple way to fix this is just to add the old download prefs. that poseFilePicker (in contentAreaUtils.js) uses to all-thunderbird.js. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/communicator/resources/content/contentAreaUtils.js&rev=1.140#504

I looked into trying to use toolkit's contentAreaUtils.js instead of xpfe's, but I couldn't quite figure out how to this. I also don't know what the other possible side-effects of using toolkit's version of this files would be.
Assignee: ispiked → mscott
QA Contact: front-end
(In reply to comment #11)
> A simple way to fix this is just to add the old download prefs. that
> poseFilePicker (in contentAreaUtils.js) uses

Oh, good catch.  In fact, I tried simply adding (via the Config Editor)
  browser.download.autoDownload
and this fixed the problem for me.  If False, you get a file-picker to select the directory; if True, it uses the directory in the (existing) pref
  browser.download.dir

I don't know why some of the get-pref call in that method are try-protected and some aren't.  I'm also not sure why (with autoDownload=false) I'm not seeing a similar exception on the unprotected fetch of
  browser.download.lastLocation
but I don't.
duplicate of bug 333607 ?
Yep, and bug 333607 has a patch. :)

*** This bug has been marked as a duplicate of 333607 ***
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: blocking-thunderbird2?
Resolution: --- → DUPLICATE
(In reply to comment #12)

> Oh, good catch.  In fact, I tried simply adding (via the Config Editor)
>   browser.download.autoDownload
> and this fixed the problem for me.  If False, you get a file-picker to select
> the directory; if True, it uses the directory in the (existing) pref
>   browser.download.dir
Since this workaround might go in as an actual fix, I decided to test this method.
Applied via config editor: user_pref("browser.download.autoDownload", false);
This seemed to work fine initially,but after some further pref tweaks:

user_pref("security.ssl3.rsa_rc2_40_md5", true);
pref("mailnews.message_display.allow.plugins", true); 

I began getting the following error in secure newsgroups:
Location: jar:file:///C:/tbtrunk101206/thunderbird/chrome/toolkit.jar!/content/global/netError.xhtml
Line Number 1, Column 1:

Will try with a fresh install (with a slower step by step pref change)


> Will try with a fresh install (with a slower step by step pref change)
> 
With a fresh zip download version 3 alpha 1 (20061014)
Set up a new separate trunk profile and added prefs with config editor:
user_pref("browser.download.autoDownload", false);
Whatever partial success I had when using my common branch profile is now gone.
While it brings up the location dialog, no file is actually copied.
Must have been something in my original profile that allowed it to (almost) work.


I'm having the same problem with V2 B1 20061206.  Right click on an image in the preview window, select "Save Image", but nothing happens.  Tried opening the message, but get the same result.
Status: RESOLVED → VERIFIED
Hardware: PC → All
build 20070104

Tried the same. Added user_pref("browser.download.autoDownload", false); and nothing happened when it was set to false.
After changing the state to TRUE, clicking the "save image" link did save the image to the folder defined by browser.download.dir

Problem partially solved....

Tested one more thing:
When trying to save an image in an RSS feed, where an actual online HTML page is displayed, the image saved got a .HTM extension. This was because the image had no extension in the HTML code of the page and I guess .HTM is the default extension when using autosave. 
This is a dupe of bug 333607. Please report any further information there. Thanks.
You need to log in before you can comment on or make changes to this bug.