334544 - 'Save image' does nothing

Status: VERIFIED DUPLICATE of bug 333607

(Thunderbird :: Mail Window Front End, defect)

Description

[walter]

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

Comment 1

[Marcel Kneuer]

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

Comment 2

[Ray Booysen]

Also on version 3 alpha 1 (20060418) Windows XP

Comment 3

[Mike Cowperthwaite]

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.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Are there any relevant JS exceptions?

Comment 5

[Mike Cowperthwaite]

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.

Comment 6

[Mike Cowperthwaite]

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

Comment 7

[Mike Cowperthwaite]

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]

Comment 8

[Adam Guthrie]

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

Comment 9

[Adam Guthrie]

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.

Comment 10

[Aimee]

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

Comment 11

[Adam Guthrie]

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.

Comment 12

[Mike Cowperthwaite]

(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.

Comment 13

[Oliver Saier]

duplicate of bug 333607 ?

Comment 14

[Adam Guthrie]

Yep, and bug 333607 has a patch. :)

*** This bug has been marked as a duplicate of 333607 ***

Comment 15

[Joe Sabash [:JoeS1]]

(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)

Comment 16

[Joe Sabash [:JoeS1]]

> 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.

Comment 17

[John Schneider]

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.

Comment 18

[Marcel Berteler]

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. 

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This is a dupe of bug 333607. Please report any further information there. Thanks.