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

NEW
Unassigned

Status

()

Core
Editor
10 years ago
7 years ago

People

(Reporter: Mircea, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
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

10 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

10 years ago
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.
Component: Message Compose Window → Editor
Product: Thunderbird → Core
QA Contact: message-compose → editor
Version: unspecified → Trunk

Comment 3

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

Comment 4

9 years ago
(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

9 years ago
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

9 years ago
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

9 years ago
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.

Updated

9 years ago
Duplicate of this bug: 484401

Updated

9 years ago
Summary: Paste problem when composing new e-mail → Paste problem when composing new e-mail (images from Microsoft Word or Excel)

Comment 9

7 years ago
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.
Depends on: 665341

Comment 10

7 years ago
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

7 years ago
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.
You need to log in before you can comment on or make changes to this bug.