487945 - Auto save breaks inline img links for non-draft edits

Status: RESOLVED FIXED

(MailNews Core :: Composition, defect)

Description

[Joe Sabash [:JoeS1]]

Edit as new any message with an inline image from any folder other than drafts.
You will soon see: Unable to save your message as draft.

Analysis/STR:

1.Set auto save to a short interval
2.Edit as new a message from any folder(other than Drafts)
3.Before the first auto-save, double click on the embedded image.
(Image link looks like this:mailbox:///C|/[Profile Data]/Inbox?number=117468334&part=1.1.2)
4.Do some editing. (Not necessarily to the image itself)
5.When you receive the "Can't save .." double-click on the IMG and observe link
(mailbox:///C|/[Profile Data]/Inbox?number=2689004&part=1.1.2)

Presumably, this is a link to the drafts folder, and not the original folder.

This happens in current Trunk, but not seen in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090225 Lightning/1.0pre Shredder/3.0b3pre ID:20090225031420

I could narrow down the regression range, if necessary.

Sev=Major, as this renders auto-save useless for anything other than Drafts.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Content-Transfer-Encoding: quoted-printable?
If yes, see Bug 487905, Bug 307023 etc.

Comment 2

[Joe Sabash [:JoeS1]]

Attachment: simple testcase

Comment 3

[rsx11m]

Reproduced with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090409 SeaMonkey/2.0b1pre, moving to MailNews Core. I can also confirm that the "number=" parameter indeed reflects the image location in the Drafts folder rather than in the originating folder, so this might even work if the folder name was just replaced with Drafts.

In further testing, the reference corruption does not seem to apply when forwarding or replying to a message and let it sit until auto-save stores a copy to Drafts, thus this seems to be specific for the Edit as New function. Also, editing as new an original on an IMAP folder with local Drafts folder does not exhibit the problem, where the "number" argument correctly refers to the IMAP folder.

Comment 4

[Joe Sabash [:JoeS1]]

Regression range:
20090225031420 works
20090226032557 fails

Comment 5

[WADA:World Anti-bad-Duping Agency]

Following is Image Property/Image Location of <img> in "Edit As New"'ed mail.
(same result with Tb 2.0.0.19 and with Tb trunk 2009/4/11 build on MS Win).
>(Test mail in IMAP Inbox)
> imap://[e-mail]:993/fetch%3EUID%3E/INBOX%3E179?part=1.1.2&filename=1a-1.gif
>(Test mail in local mail folder)
> mailbox:///C|/(...snip...)/Mail/a.a.a/Bug-Test.sbd/bug-487945.eml?number=0&part=1.1.2&filename=1a-1.gif

But I couldn't observe "Can't save" nor "Fetch error".

Bug 461785 reports similar phenomena to yours. And above Image property is reported in that bug too.
Joe Sabash, do you use HTML signature with <img>?

Comment 6

[rsx11m]

>(Test mail in IMAP Inbox)

WADA, as stated in comment #3, you have to use a message in a local folder,
this doesn't occur when editing as new a message from an IMAP account.

Bug 461785 comment #7 looks more like bug 307023 to me, which does *not* apply in the case here (not a quoted-printable message, reproducible with 7bit).

Comment 7

[Magnus Melin [:mkmelin]]

Regression window checkins:
http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-02-25+03%3A14%3A20&enddate=2009-02-26+03%3A25%3A57  ... or maybe it's something on m-c.

Comment 8

[Joe Sabash [:JoeS1]]

This is fixed by checkin of bug 692875
Thunderbird 10.0 and above