437217 - Paste problem when composing new e-mail (images from Microsoft Word or Excel)

Status: NEW

(Core :: DOM: Editor, defect, P5)

Description

[Mircea]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Avant Browser; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: version 2.0.0.14 (20080421)

Context: compose an HMTL content based e-mail

Paste some graphic content from the clipboard.


Reproducible: Always

Steps to Reproduce:
1) Draw something in winword
2) Copy what you have drawn to the clipboard
3) Go to the e-mail composition window and paste the content of the clipboard
4) Go back to the winword document
5) Change the drawing there
6) Copy the new drawing to the clipboard
7) Go to the e-mail composition window and paste the content of the clipboard

Actual Results:  
You will get the very first drawing on the clipboard (and not the latest one).


Expected Results:  
You should be able to paste the latest drawing you have put on the clipboard.

Note: To "reset" the behaviour and to be able to paste the latest clipboard content, you need to restart Thunderbird Mozilla.

Comment 1

[Dale Wiggins]

I see this also. Also, if I save, close and reopen the composition window, it correctly shows the new image but doing another paste still shows the old image.

Comment 2

[rsx11m]

I see this behavior on 3.0a2pre (Windows/2008060403) when pasting from MS Word, the correct (new) figure is pasted into MS Paint. However, I don't see this when pasting from MS PowerPoint, the second figure pastes correctly then.

Same on SeaMonkey 1.1.9 (Windows NT 5.1, Gecko/20080313), both for Mail & News and Composer, thus this is Core code. I'm also not sure if the bug would be in
MS Word rather than Mozilla, hard to determine without the clipboard contents.

Comment 3

[rsx11m]

Jim, is this more likely Widget code than a potential Editor issue?

Comment 4

[Jim Mathies [:jimm]]

(In reply to comment #1)
> I see this also. Also, if I save, close and reopen the composition window, it
> correctly shows the new image but doing another paste still shows the old
> image.

This to me makes it sound like it's in the composition view. The correct data is getting handed in from widget, but not displayed correctly. Just a guess. I'll take a look at the receiver side in widget to see if I can spot anything though.

Comment 5

[rsx11m]

There are also bug 404922 and bug 383336, describing old content being displayed when an image file is dragged-and-dropped twice with its content changed, where the preview image (or how you want to call it) stays the same until the message is actually sent.

What made me suspicious though is that the pasting issue here occurs only when pasting from certain applications, such as MS-Word. Retesting this and looking closer into the details, it seems to be using a different mechanism than usually pasting an image, specifically no temporary moz-screenshot-*.xxx file is created.

When pasting from MS-Word, the application itself creates a temporary file in C:\Documents and Settings\...\Local Settings\Temp\msohtml* which is then *reused* when pasting multiple drawings. Thus, indeed this may be specific to that application, prompting bug 404922 in the process, actually sending only the last pasted drawing with multiple references to it. This would also explain why pasting from MS-Paint in this way doesn't trigger the issue, given that the moz-screenshot files are always unique.

Comment 6

[Jim Mathies [:jimm]]

A paste into the editor of the same file should probably trigger a refresh of the content. Maybe somewhere in there we need to add something that flushes the image from the cache?

Comment 7

[rsx11m]

The cache is one issue, the more important restriction may be that the editor uses the same content then for both paste operations = the content of the first paste was not stored elsewhere and therefore is overwritten when the second copy operation is performed. So, that's a more general problem of grabbing the actual data only at the time of encoding the message, also reflected in the drag-and-drop bugs I referred to in comment #5.

Comment 9

[rsx11m]

Bug 665341 may resolve the issue here by converting the contents of the temporary file produced by MS Office into a unique data: URI representation.

Comment 10

[rsx11m]

Ok, so bug 665341 kept everything as is with the argument that this is HTML code generated by MS Office itself and hence won't be converted, thus the issue of caching a wrong image and not updating it remains. However, just reviewing my comment #5, this may have been fixed by bug 404922 and needs re-testing if the issue still applies.

Comment 11

[rsx11m]

Bug 404922 was fixed by bug 609632 making drag-and-drop a data: URI, in this way bypassing the underlying problem. This specific bug is still reproducible in current Gecko 5.0 builds, thus reconfirmed.

Comment 12

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.