Closed Bug 244780 Opened 20 years ago Closed 20 years ago

Change in Image Loading policy broke "Save Image As"

Categories

(Thunderbird :: General, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird1.1

People

(Reporter: superbiskit, Assigned: mscott)

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040523 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040523 Firefox/0.8.0+

Thunderbird Nightly 0.6+ (20040525) on Windoze XP

If I select "Save Image As . . .", referencing a web-resident image, the "Saving
" status box comes up but never never never makes any progress.  The image is
not, in fact, downloaded.  This despite the fact that it is already sitting in
the cache on my 'puter -- I know that 'cause I'm looking at the image.

Saving several, yesterday, without checking completion, I had 24 "Saving " boxes
stacked up behind the visible window - and none of them were going anywhere.

As before, if I save the email as html-file and open it in Firefox, the messages
can be saved without any problem.

Reproducible: Always
Steps to Reproduce:
1. Tools->Options->Advanced Privacy: UNCHECK "Block images . . . ."
2. Load a page with multiple images
3. ContextMenu:Save_Image_As, Enter a filename.

Actual Results:  
a. "Saving " status box pops up
b. The UI is active, so I can bring TBird back to the top and try another image
c. Bring (one of) the Saving box(es) back to the top -- observe that no bytes
have been downloaded and nothing at all is happening.

Expected Results:  
The image should be loaded and saved.

Given that the image is already present in cache, I don't understand why it
cannot be saved from there but must go back on the 'net to re-get it.

My SWAG is that this relates to <Bug#243852> and/or <Bug#243535>.

I assigned it as "General" -- should be something like "Networking" (?)
the image loading policy change isn't a part of the aviary 1.0 branch so this
isn't a 1.0 stopper. But is an annoying trunk regression we should try to track
down. 

It showed up during hte image loading policy landing. I'm guessing it was caused
by that. 
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Thunderbird0.8
works for me with thunderbird 0.6+ (20040529) (form latest-trunk)
If i open a mail with <img src="http://somethin"> i can save the image to disk
using save image as.
re: comment#2
version 0.6+ (20040530) on WinXP

Bug is still present.
Then we need more info.
How is the image embedded in the email? Can you attach a mail that shows the
problem? Does it happen with only one email, or all emails?
What context menu are you opening? right click on the image?
doesn't effect branch builds so not a 1.0 stopper.
Target Milestone: Thunderbird0.8 → Thunderbird1.0
Is this perhaps related to this discussion in a forum?  (I am the second
poster.)  The message I tried it with contained a few lines of text and an
embedded jpg.

I installed Thunderbird 0.8 on Linux/Fodora - it does work Smile

When I open a *.eml ("File / Open saved massage ...") JPGs and GIFs contained in
this Email are not shown. Is there an option I have to set (or is this function
already missing)?

Thx, Reinhard
    
I tried this on Windows, and the image was not displayed either. I opened the
saved message with Outlook, and the image was there.

Karenanne
Target Milestone: Thunderbird1.0 → Thunderbird1.1
This has been a condition on the trunk builds for months now. In regard to
comment #4 No particular testcase or conditions should be necessary to reproduce
this bug. Any Image placed in an email as inline content 'insert image' will
demonstrate this bug.I can verify that this bug exists in Win98 and WinXP pro.
There are quite a few feature/optimizations that exist on the trunk builds, that
I would like to test, but this bug makes that very difficult to use trunk builds
as my 'everyday' mail/news program.
JoeS
 
#c1
Mscott, do you have a bug reference for this 'hte' checkin, I would like to
comment on it as a regression.
Joes: Bug #191839 maybe?
reconfirming this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6)
Gecko/20041224
I don't see an option here for blocking 1.8a6 but this semms to be a blocker to me 
(In reply to comment #10)
> reconfirming this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6)
If you see this on seamonkey, file a new bug. Tihs bug is thunderbird only.
Bug #191839 was landed on branch, so if this is not an issue on branch I don't
see how that bug would have caused it...

What is the actual regression window for this breaking on trunk?
(In reply to comment #12)
> Bug #191839 was landed on branch, so if this is not an issue on branch I don't
> see how that bug would have caused it...
> 
> What is the actual regression window for this breaking on trunk?

20040805 is OK
20040809 is broken Curiously the version number in this build reverted to 0.6+
even though I know the build was done on 08/09/04
JoeS
Joe, what are the actual timestamps on those builds?  Are they morning,
afternoon, evening builds?
(In reply to comment #14)
> Joe, what are the actual timestamps on those builds?  Are they morning,
> afternoon, evening builds?
The 08/05 build is a 3rd party build (Moox) who includes his cvsco.log here are
the pull times in the log.
checkout start: Thu Aug 5 07:41:08 CST 2004 
checkout finish: Thu Aug 5 07:55:46 CST 2004 
The 09/09 build was a zip build that I downloaded on 08/09/04 7:14 PM E.S.T
The Thunderbird.exe has a last modified tag of 08/09/04 1:48 AM
I had to jockey around some removeable hard drives,but I now can look further at
the files if you need more info.
Joe

comment 0:
> Thunderbird Nightly 0.6+ (20040525) on Windoze XP

comment 13:
> 20040805 is OK
Are you sure it is the same problem? Are you sure that build is from trunk?
Otherwise it has been fixed, and then broken again later.
(In reply to comment #16)
> comment 0:
> > Thunderbird Nightly 0.6+ (20040525) on Windoze XP
> 
> comment 13:
> > 20040805 is OK
> Are you sure it is the same problem? Are you sure that build is from trunk?
> Otherwise it has been fixed, and then broken again later.
It identifies itself as a trunk build,here is the complete log on that build:

checkout start: Thu Aug 5 07:41:08 CST 2004
M mozilla/nsprpub/lib/ds/plhash.c
? mozilla/security/nss/cmd/zlib/crc32.h
M mozilla/security/nss/cmd/zlib/crc32.c
M mozilla/modules/libpr0n/decoders/bmp/nsBMPDecoder.cpp
M mozilla/modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp
? mozilla/modules/zlib/src/crc32.h
M mozilla/jpeg/jdapimin.c
M mozilla/jpeg/jdcoefct.c
M mozilla/jpeg/jdcolor.c
M mozilla/jpeg/jddctmgr.c
M mozilla/jpeg/jidctint.c
M mozilla/jpeg/jmemmgr.c
M mozilla/js/src/js.c
M mozilla/js/src/jsarray.c
M mozilla/js/src/jsbool.c
M mozilla/js/src/jsdate.c
M mozilla/js/src/jsemit.c
M mozilla/js/src/jshash.c
M mozilla/js/src/jsinterp.c
M mozilla/js/src/jsmath.c
M mozilla/js/src/jsnum.c
M mozilla/js/src/jsparse.c
M mozilla/js/src/jsstr.c
M mozilla/js/src/liveconnect/jsj_hash.c
M mozilla/js/src/xpconnect/src/Makefile.in
M mozilla/modules/zlib/src/crc32.c
M mozilla/xpcom/ds/pldhash.c
checkout finish: Thu Aug 5 07:55:46 CST 2004 
and the Mozconfig
# Built by MOOX - http://moox.ws/tech/mozilla
# Source: Mozilla HEAD
# TRUNK .mozconfig
# Last edit: 2004.07.23

. $topsrcdir/browser/config/mozconfig

export BUILD_OFFICIAL=1
mk_add_options BUILD_OFFICIAL=1

ac_add_options --disable-accessibility
ac_add_options --disable-activex
ac_add_options --disable-activex-scripting
ac_add_options --disable-composer
ac_add_options --disable-debug
ac_add_options --disable-installer
ac_add_options --disable-ldap
ac_add_options --disable-mailnews
ac_add_options --disable-pedantic
ac_add_options --disable-profilesharing
ac_add_options --disable-shared
ac_add_options --disable-tests
ac_add_options --enable-crypto
ac_add_options
--enable-extensions=cookie,xml-rpc,xmlextras,p3p,pref,universalchardet,inspector,transformiix,typeaheadfind,webservices
ac_add_options --enable-necko-small-buffers 
ac_add_options --enable-static
ac_add_options --enable-strip
ac_add_options --enable-strip-libs

# Optimization configurations
# ac_add_options --enable-optimize="-Oxp -GAF7s"
# ac_add_options --enable-optimize="-Oxp -GAF6s"
ac_add_options --enable-optimize="-Oxp -GA5s"


# Enable SVG option
# ac_add_options --enable-svg
# ac_add_options --enable-svg-renderer-gdiplus 


Well, digging around my archives and backups, the closest 'official' trunk build
I could find to the original bug post build is 0.5+(20040409) This bug is not
present in that build.I'll see if I can find anything closer.
If someone can give me clear steps to reproduce (the ones in comment 0 are
pretty insufficient, since it's not clear to me how I "load a page with multiple
images" in a mail client), I can try and see whether I can narrow this down
too.... I'd assume the steps would start with "send yourself an HTML mail with
the following HTML" or so.
Be careful it might open with OE but that's another problem
Steps to reproduce:
1 Compose an email in HTML mode with any image inserted via Insert | Image dialog
2 Send it in HTML only format (may not be absolutely necessary)
3 Make sure that View |message body as| is set to HTML
4 Open the message and right click the image and choose |save as..
5 The 'Save Image' dialog will appear,select a destination folder and click save
6 The 'Saving image' box appears,but does not copy the image to the selected folder
I tried the steps in comment 21.  In a current trunk SeaMonkey build, they work
for me.  In a current trunk thunderbird build, the context menu is busted; I get
errors in the JS console just bringing it up, and the options don't work.

Given that the regression range listed in comment 13 doesn't include any content
policy changes, I'm not sure why bug 191839 is being blamed...

On a separate note, the -1 that imap channels return for their content length
gives nsWebBrowserPersist conniptions, but such is life.
cool thanks for testing Joe. 
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: