247817 - image data lost by Insert HTML once a draft message is saved

Status: RESOLVED DUPLICATE of bug 224733

(Thunderbird :: Mail Window Front End, defect)

Description

[Dan M]

(Recent trunk builds)

1) Write a new HTML message.
2) Drop an image into the body (not as an attachment).
3) Save it to your Drafts folder.
4) Open it. Select the image, Insert Menu -> Insert HTML.
--- Ja, that's a geek feature. But I can hardly get a message to look
    the way I want without editing its HTML ---
5) Make any change. For example add |style="float: left"| to the <img> tag.
   Click Insert.

The image is gone, replaced by the broken placeholder icon.

Workaround: the image isn't lost if you use Image Properties rather than Insert
HTML. This becomes more problematic if you edit HTML that happens to span an
image; an act sometimes necessary to avoid causing problems at the boundaries of
your edit.

Comment 1

[Paolo Brocco]

(In reply to comment #0)
This problem also occurs if I click "insert" > "Image..." > under "Image
Location" I put the url of an image (e.g.
http://www.mozilla.org/images/ico-ff.png) > I save it as Template (or Draft) >
the saved message automatically includes the image (of 5 KB) instead of letting
the URL.
It would be nice to be able to vote for this. How is it possible to do so?

Comment 2

[Dan M]

That's bug 176416 or possibly bug 132257, and completely unrelated to this bug.

Comment 3

[Mike Cowperthwaite]

Dan M, this bug appears to have been fixed by the updated patch to bug 192557.
I'm seeing the image restored to the draft using
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040710

I'm resolving this as fixed; please mark this bug Verified if it's working for 
you, or reopen if you're still seeing the problem (along with additional 
information on how to duplicate).

Comment 4

[Dan M]

Well no, nothing seems to have changed. The original steps still apply. I
intended to mean to close the message between steps 3 and 4, so you could
(re)open it in step 4. You're saving, closing, then reopening?

I've verified the bug is still present in my own 20040712 Windows build, and
also in the thunderbird-win32.zip build downloaded from
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2004-07-12-07-trunk/
. I tried this with my real profile, and with a new profile. The bug shows up
every time.

Can I whine about how many new fairly scary bugs I turned up while trying to
find a way to not reproduce this one? Tester folks should try using a brand new
profile once or twice before this thing ships.

Comment 5

[Joe Sabash [:JoeS1]]

Related to or Dup of ?
http://bugzilla.mozilla.org/show_bug.cgi?id=224733
There is a workaround after you change the html data

Comment 6

[Dan M]

I've read bug 224733 several times and still can't figure out exactly what it's
saying. But yes, this bug is arguably caused by the transition of the embedded
image's filename from straight filesystem parlance to a form that seems to
attempt to identify the attachment within its message. The second form doesn't
appear to me to be over-escaped. These bugs are probably related in some way,
but I'm guessing they're not exactly the same. I'm marking this bug dependent.

Comment 7

[Joe Sabash [:JoeS1]]

Attachment: Text file describing a work-around

How to rescue the lost images

Comment 8

[Joe Sabash [:JoeS1]]

Bug 244733 was difficult to describe because copy/paste re-converted the
errant characters. Hopefully the attached txt file will be readable.
Be aware also the the scope of the html edit window can be limited by
selecting (highlighting) just the element whose html you wan to edit.
In my practice I usually 'select |all ' then 'insert |html' which really 
amounts to 'edit all the html in the body'
Sometime this means restoring the links to 6 or more images.

Comment 9

[Dan M]

Oh that's the over-escaped part. This is a duplicate bug, then. I'll close it
then, but reluctantly because I think it's a lot more clear than the older bug
report. Maybe that's just because I wrote this one up. Adios.

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