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.

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

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.

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

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

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.

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.

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.

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

I saw that security error when testing yesterday with 1.5.0.9.

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

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.

blocked by bug 282649?

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.

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

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 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...

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

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 on attachment 253279 [details] [diff] [review] updated fix yeah, better safe than sorry, I think.

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.

same fix, ported to the branch

verified fixed with Seamonkey 1.5a-0130, Win2K.

Also v with TB 2b2-0131.

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