343933 - Inserted inline images not displayed after message save

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[Telmo Amaral]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

When composing an HTML message, images dragged-and-dropped from Windows Explorer are correctly inserted only if the message has not been saved. Once the message is saved (manually or automatically), the images are no longer correctly inserted; a square picture handler containing a red dot appears in its place.

Reproducible: Always

Steps to Reproduce:
1. Open a new compose window in HTML format
2. Drag-and-drop one or more image files into the message body
3. Save the message (e.g. by pressing Ctrl+s or by waiting until auto-save happens)
4. Drag-and-drop one or more image files into the message body again.
Actual Results:  
The images pasted after saving the message are not inserted; a square picture handler containing a red dot appears in its place.

Expected Results:  
All images should be correctly inserted, regardless of saving the message or not.

Happens on POP, IMAP, and newsgroup accounts and was tested with JPEG files under 100 KB.

Comment 1

[moz.champion]

(In reply to comment #0)
Can add Macintosh to this bug as well.
Reproduced by following steps 

Comment 2

[Chris Ilias [:cilias]]

Confirmed on Tb trunk (2006070703) and 1.8.1 branch (2006070705), as well as SeaMonkey trunk (2006070709), and SeaMonkey 1.0.2 release.
[all on Windows XP]

Product moving to Core.
Hardware and OS moving to All (based on comment #1 ).

Also note: I've changed the summary, because this also affects inserting images via the formatting toolbar of the Insert menu; and the image *is* displayed in the message, when clicking on the Drafts folder (you need to save it again). The image is also sent; so this only seems to be a display issue in the composition window.

Still looking for a dup.

Comment 3

[Mike Cowperthwaite]

Be careful saving the draft more than once, however: bug 319818.

Comment 4

[Mike Cowperthwaite]

I notice this happens also in an HTML reply or forward, before saving a draft.

Comment 5

[Peter Lairo]

version 3 alpha 1 (20061214), WinxP:

1. open HTML compose window
2. paste (CTRL+V) a screenshot
--> image *is* displayed

3. CRTL+S (save as draft)
4. look at message in draft folder
--> image *is* displayed

5. double-click on message in draft folder
--> image *is* displayed

7. paste again (after the save in step #3)
--> image is *not* displayed                <-- this bug

Autosave evey 5 minutes (very useful) makes this bug very visible and annoying.

Comment 8

[Mike Cowperthwaite]

Now that Seth's reported this bug, perhaps we can get some interest in getting it fixed.  :)  Altho: bug 319818, mentioned above, results in a hang, it probably should be addressed first.

Comment 9

[(not reading, please use [e-mail] instead)]

note, in addition to pasting directly, attempting to use the "Insert | Image" menu item gives me the same problem.

Security Error: Content at about:blank may not load or link to file:///C:/Documents%20and%20Settings/mozilla/Desktop/for%20pkim.PNG.

Comment 10

[Scott MacGregor]

Seth, do you see the Security Error: on the branch or just the trunk?

Comment 11

[Mike Cowperthwaite]

I saw that security error when testing yesterday with 1.5.0.9.

Comment 12

[(not reading, please use [e-mail] instead)]

scott:  the branch.  I'm seeing it on tbird version 2 beta 2 (20070118) windows xp, to be exact.

Comment 13

[Joe Sabash [:JoeS1]]

The same with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070118 Thunderbird/3.0a1 ID:2007011803
Error occurs only after a save, either auto-save or manual.
Also if you double-click on a previously inserted image, again only after the save
has been done, and the error is logged multiple times in this case.

Comment 14

[Worcester12345]

blocked by bug 282649?

Comment 15

[Scott MacGregor]

This is a very recent regression and is not Bug 282649. On a side note, I tested the patch in 282649 and it didn't help with this issue :(.

Ah, it looks like when we save a message as a draft the app type on the editor docshell is getting chnaged to something other than editor. This causes us to go through different security checks. 

Comment 16

[Scott MacGregor]

Attachment: one approach

This approach skips nsmsgWindow::SetRootDocshell's attempt to change the app type for compose windows.

Comment 17

[Scott MacGregor]

Attachment: another approach

This is a slightly riskier approach (because we may miss a spot where we want to set the app type to mail for a root docshell), but I like it better. It removes app type knowledge from nsMsgWindow::SetRootDocshell, pushing the burden to the application chrome layer.

Comment 18

[David :Bienvenu]

Comment on attachment 253257 [details] [diff] [review]
another approach

what about address book windows? And we run urls from the folder properties dialog when you do a download now, but we might use the parent msg window for that...

Comment 19

[Scott MacGregor]

Your right. I'm still missing a couple places where we set a dom window on nsIMsgWindow object and where we should also set an app type on the root docshell. Here's the full list of callers:

http://lxr.mozilla.org/mozilla/search?string=window.domWindow

Comment 20

[Scott MacGregor]

Attachment: updated fix

I think some of these calls are unnecessary, but this ensures we have the same behavior we have today for when we set the app type on the root docshell.

Comment 21

[David :Bienvenu]

Comment on attachment 253279 [details] [diff] [review]
updated fix

yeah, better safe than sorry, I think.

Comment 22

[Scott MacGregor]

ok, this is fixed on the trunk. It will require a separate patch for the branch due to API changes to nsIMsgWindow::SetDOMWindow that are trunk only.

Comment 23

[Scott MacGregor]

Attachment: ported to the 1.8 branch

same fix, ported to the branch

Comment 24

[Mike Cowperthwaite]

verified fixed with Seamonkey 1.5a-0130, Win2K.

Comment 25

[Mike Cowperthwaite]

Also v with TB 2b2-0131.

Comment 26

[Carsten Book [:Tomcat]]

verified fixed for 1.8.1.2 using the steps to reproduce from comment#0 using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.2pre) Gecko/20070208 Thunderbird/2.0pre Mnenhy/0.7.5.0 ID:2007020804