925132 - Bug. TB fails to attach embedded images. Upon the 2nd save or auto-save the images vanish.

Status: VERIFIED INCOMPLETE

(Thunderbird :: Message Compose Window, defect)

Description

[Alex]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

It's related to replying to an email which had embedded images. If you save (or auto-save) them a second time the images vanish. And the composed email can not be saved or sent anymore. A endless "Attaching.." dialog comes up.

It's a often posted problem and still existing in version 24. So I think I can ignore older bug cases reported to you. I didn't find new solutions.

There is even already a public video for it:
http://youtu.be/mjEld6warOA

And the description is here:
http://forums.mozillazine.org/viewtopic.php?f=39&t=2459519&start=60





Actual results:

See above.


Expected results:

The embedded images should not get lost. The email should be saved successfully unlimited times and sent when I'm ready to do so.

Comment 1

[Thomas D. (:thomas8)]

Alex, thank you for your bug report and sorry for the inconvenience.
We have several bugs on record wrt inline images, so most likely your issue has already been filed:

tentative search
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Athun%2Cmailn%20attach%20inline%2Cembed%20imag%2Cpict&list_id=8587712

If you see your problem in one of these bugs, pls mark this bug as a duplicate.

We need volunteers with skill, time, will to analyse and fix them.

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to Alex from comment #0)
> A endless "Attaching.." dialog comes up.
>(snip) 
> It's a often posted problem and still existing in version 24.
> So I think I can ignore older bug cases reported to you.

What is difference of your problem from already known(and not resolved yet) bug 817245/bug 453196, or bug 532395?
Note: bug 532395 == (a) bug 817245, bug 453196
                  + (b) bugs listed in dependency tree for (a)
                  + (c) some bugs listed in dependency tree for meta bug 877159
                  + (d) different problem from (a), (b), (c)

Comment 3

[Thomas D. (:thomas8)]

WADA, thanks for trying to clear this up by focussing on more precise analysis.

I see a new element in this bug not covered by the bugs you quote in comment 2, which is same as in bug 974404:

Certain images (without extension; ...) vanish only after the *2nd* saving as draft. And in my testing of that, "Attaching..." error message did *not* occur.

Alex (reporter) wrote to me via pm that he agrees bug 974404 is his issue filed here.
So I think it's OK to dupe to that bug, focusing on the unique feature of 2nd saving problem.

I'm aware that this decision will overlook some other details in comment 0 which look like bug 532395 and friends, but I think we have to live with some fuzziness in users bug reports; it's easy to get confused about the details of scenarios. E.g., unless user is aware of difference between images with and without extension, he'll be unable to provide accurate description. And to user, broken image (without error message) or broken image (with "attaching..." error message) is almost the same, so I think it's not easy to expect a very high degree of precision (as required for bug fixing) from the reporting users.

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to Thomas D. from comment #3)
> I see a new element in this bug not covered by the bugs you quote in comment 2, which is same as in bug 974404:
> Certain images (without extension; ...) vanish only after the *2nd* savin as draft. 
> And in my testing of that, "Attaching..." error message did *not* occur.
> Alex (reporter) wrote to me via pm that he agrees bug 974404 is his issue filed here.
> So I think it's OK to dupe to that bug, focusing on the unique feature of 2nd saving problem.

Thomas D., why can this bug be DUP of bug 974404 which won't produce phenomenon of "endless Atacching...", even though bug opener of this bug says phenomenon of "endless Atacching..." surely ocurred?

Comment 5

[Thomas D. (:thomas8)]

(In reply to WADA from comment #4)
> (In reply to Thomas D. from comment #3)
> > I see a new element in this bug not covered by the bugs you quote in comment 2, which is same as in bug 974404:
> > Certain images (without extension; ...) vanish only after the *2nd* savin as draft. 
> > And in my testing of that, "Attaching..." error message did *not* occur.
> > Alex (reporter) wrote to me via pm that he agrees bug 974404 is his issue filed here.
> > So I think it's OK to dupe to that bug, focusing on the unique feature of 2nd saving problem.
> 
> Thomas D., why can this bug be DUP of bug 974404 which won't produce
> phenomenon of "endless Atacching...", even though bug opener of this bug
> says phenomenon of "endless Atacching..." surely ocurred?

Well, I tried to explain my reasons for duplicating against bug 974404 in the very comment you replied to, but apparently they weren't convincing enough -> back to unconfirmed.

WADA, I was focusing on this aspect of comment 0:
> If you save (or auto-save) them a second time the images vanish.

That's same STR as found in my comment bug 974404 comment 1 (which perhaps isn't the same as bug 974404 comment 0), and as I said, I think that's something very remarkable which we should analyse: each time of 1st, 2nd, 3rd saving of draft, the actual draft source (as seen in msg reader) changes, and it gets worse every time, ending up in two text/html parts where there should be just one and the image.

You are right, I decided to ignore comment 0 statement about "attaching..." error because I think perhaps it does not always occur. I still think so, because of following explanation by reporter of this bug (Alex) via pm:

> (b)
> One more thing. I looked to a few other reports. They are similar. But they make guesses, report it
> is sometimes or happens after a while or only to certain messages IMAP / HTML / offline and so on.
> My case is constantly, every reply and reproducible. So better to control and investigate on.
> I'm open to cooperate with everybody who participates to solve the issue.
> Thanks! Alex

WADA, how can this bug be duplicate of bug 817245 (as reporter claimed via pm)?
(a) bug 817245 only happens occasionally and unpredictably when compact happens to co-occur with current composition; but
(b) reporter claims that this bug occurs "constantly, every reply and reproducible"?

So if (a) was true: for every reply, compact just co-occurs at the exact time to break the reply? I think that's unlikely.

Comment 6

[Thomas D. (:thomas8)]

But well, all our efforts of sorting these bugs out are futile as long as there's nobody fixing them...

Comment 7

[Wayne Mery (:wsmwk)]

Should we dupe? Or should we confirm?

Comment 8

[Thomas D. (:thomas8)]

I won't try duping (which is pointless without clear STR).
I tried a couple of scenarios (pretty tedious) and cannot reproduce on 78.10.1 (32-bit) - but then, there are no clear STR and images can be added in many different ways - linked, linked+attach-on-send, data-URL, via signature, reply might double the signature etc...

I can sometimes see data-URLs being created now - we might have fixed some problems here.

Alex H. (reporter) - can you still reproduce?
Anyone?

Comment 9

[Thomas D. (:thomas8)]

There are also weird UX states - like for an image with data: URL, you can still uncheck "Attach this image to the message" - what's the expected outcome of that? (When the image is already fully contained in the data URL, that checkbox should probably be checked and disabled).

Comment 10

[Thomas D. (:thomas8)]

Reporter is gone (account disabled), and filing this bug appears to have been his only activity ever.
Nothing to do here any more. There might be bugs under some odd circumstances - but without knowing the circumstances it's pointless.