After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 258374 - Clipboard cleared on mail close
Clipboard cleared on mail close
Product: GtkHtml
Classification: Other
Component: Parsing
Other other
: High normal
: 2.8
Assigned To: gtkhtml-maintainers
Evolution QA team
: 317001 343971 410059 463066 (view as bug list)
Depends on:
Reported: 2004-05-12 12:27 UTC by Tim Parkin
Modified: 2009-11-27 04:11 UTC
See Also:
GNOME target: ---
GNOME version: ---

workaround patch (3.38 KB, patch)
2006-05-24 11:45 UTC, Hiroyuki Ikezoe
none Details | Review
new patch (18.91 KB, patch)
2006-07-28 04:43 UTC, Hiroyuki Ikezoe
needs-work Details | Review
revised patch (19.90 KB, patch)
2006-09-10 08:21 UTC, Hiroyuki Ikezoe
none Details | Review
revised patch (20.44 KB, patch)
2006-09-11 06:11 UTC, Hiroyuki Ikezoe
needs-work Details | Review
A new patch (19.52 KB, patch)
2007-08-27 04:00 UTC, Hiroyuki Ikezoe
committed Details | Review
simple test program (864 bytes, text/x-csrc)
2007-10-14 07:17 UTC, Hiroyuki Ikezoe

Description Tim Parkin 2004-05-12 12:27:12 UTC
Description of Problem:

1) No right click menu on mail body text (although if I click in the
backgroun d of the text I get the mail context menu)

2) If I <ctrl> C on a block of text in an open mail and then close the
mail, the clipboard copy is lost. This is the major annoyance

Expected Results:
1) A right click menu as appears when right clicking in highlighted content
of 'to:' field

2) Leave content in clipboard on mail item close

How often does this happen? all the time,
Comment 1 André Klapper 2004-12-27 18:05:28 UTC
1st one is a dup of bug 255803 and already fixed, therefore changing 
the subject...
Comment 2 Leon Stringer 2005-12-12 20:09:10 UTC
I see number 2 too but can't change the bug status to CONFIRMED.

I tested with Evolution 2.5.2.

To reproduce this:

1. Start Evolution.

2. Click on the New Mail Message toolbar button.

3. Type "Test" into the message body.

4. Select the word Test with the mouse, right-click and select "Copy" from the
pop-up menu.

5. Close the message window (e.g. from the top-left "X" icon) and choose
"Discard Changes" when prompted.

6. Click on the New Mail Message toolbar button again.

7. Right left-click into the message body (to move focus), then right-click and
select "Paste". Nothing happens.
Comment 3 Sebastien Bacher 2006-04-14 10:38:12 UTC
*** Bug 317001 has been marked as a duplicate of this bug. ***
Comment 4 Sebastien Bacher 2006-04-14 10:54:45 UTC
Ubuntu bug about that:
Comment 5 Matthew East 2006-04-21 08:30:15 UTC
This bug will annoy the hell out of users who switch from Windows and are used to this Just Working. As a result, I'm marking it up to Normal Severity. Is there any chance of this being fixed soon?
Comment 6 Hiroyuki Ikezoe 2006-05-19 14:26:54 UTC
This bug is caused by GtkHTML, not Evolution.
Comment 7 Hiroyuki Ikezoe 2006-05-24 11:45:17 UTC
Created attachment 66118 [details] [review]
workaround patch

Cpoying "copied text" to clipboard explicitly when widget is destroyed.
Comment 8 Hiroyuki Ikezoe 2006-05-24 11:46:28 UTC
It's just copied plain text. Not HTML text.
Comment 9 André Klapper 2006-06-08 11:36:29 UTC
*** Bug 343971 has been marked as a duplicate of this bug. ***
Comment 10 Hiroyuki Ikezoe 2006-07-28 04:38:44 UTC
I'm sorry, my patch was wrong.  In some cases, the clipboard text composed by other application is overwritten by  GTKHtml's copying text.

Step reproduce it:

1. Copy text in Evolution mail composer
2. Cope text in some other application 
3. Close Evolution mail composer
4. Do paste command in some application
5. Ugh! Pasting Evo's text

I reworked a new patch with GtkClipboard, I attach it.
Comment 11 Hiroyuki Ikezoe 2006-07-28 04:43:26 UTC
Created attachment 69783 [details] [review]
new patch

Use GtkClipboard instead of selection_get or selection_received signals.
Comment 12 André Klapper 2006-08-21 19:47:59 UTC
moving to gtkhtml.
should be reviewed in the 2.8 or 2.9 cycle - srini?
Comment 13 Srinivasa Ragavan 2006-08-24 14:38:51 UTC
Hiroyuki, Your patch works only in composer. Even if you close, and open composer, it preserves. If you close evolution every thing is lost. Definitly this patch seems OK to commit, but that also should be addressed IMO.
Comment 14 Hiroyuki Ikezoe 2006-09-10 08:20:59 UTC
Srini, Thank you point it out. And I noticed I did not handle primary selection too.

I revised my patch and attach it here.
Comment 15 Hiroyuki Ikezoe 2006-09-10 08:21:44 UTC
Created attachment 72485 [details] [review]
revised patch
Comment 16 Hiroyuki Ikezoe 2006-09-11 06:11:06 UTC
Created attachment 72529 [details] [review]
revised patch

My previous patch has two problems:

* Crash when DnD from
* Cannot copy from GtkHTML itself when the first paste action. (i.e. Ctrl+V does not happen after Ctrl+C in GTKHTML, but then Ctrl+V works fine.)

The first one is solved in this patch.

The second one is caused by the code which I added for reserving copied string after closing evolution (i.e. to solve the situation in comment #13).  So I removed the code.

I have to work to solve the issue in comment #13.
Comment 17 Daniel Holbach 2006-09-27 15:14:39 UTC
Is this patch 2.8.x material?
Comment 18 Srinivasa Ragavan 2006-09-27 18:32:06 UTC
Daniel, Hiroyuki is yet to close on the second one.
Comment 19 Kjartan Maraas 2007-01-25 15:47:02 UTC
Any progress on this? Can we please get the patches marked with some form of status?
Comment 20 Karl 2007-04-14 15:06:55 UTC
How likely is this to be fixed before the next release? it would be great if this could be fixed and we have 'expected' copy and paste.
Comment 21 Srinivasa Ragavan 2007-08-23 11:16:27 UTC
Setting patch status on to needs-work based on comment #18. I would love to get this bug fixed completely for this release.
Comment 22 Hiroyuki Ikezoe 2007-08-27 03:59:54 UTC
Sniri, I have not found the solution for the issue that text data has gone when evo  is closed (you mentioned in comment #13). I guess GTK+ does store handle raw text and other format data in clipboard when application has closed. 

Anyway, I think that keeping the clipboard data only while application is running is useful.

I attach a new patch.
Comment 23 Hiroyuki Ikezoe 2007-08-27 04:00:54 UTC
Created attachment 94407 [details] [review]
A new patch

A new patch to latest trunk.
Comment 24 Murray Cumming 2007-08-27 07:46:02 UTC
> I have not found the solution for the issue that text data has gone when evo is closed

Your patch already uses gtk_clipboard_set_can_store():
so I would expect this to work.
Comment 25 Srinivasa Ragavan 2007-08-29 04:34:42 UTC
Murray, unfortunately it doesn't work. If you close Evolution, all the clipboard contents are reset. But it works at least if the message window is closed.  I'm fine to push this and leave the bug open with the summary adjusted. Hiroyuki, Im sure that you can debug the reset later-on.
Comment 26 Murray Cumming 2007-08-30 07:47:22 UTC
That sounds sensible. It will make it easier for someone to figure out how to fix it completely.
Comment 27 Hiroyuki Ikezoe 2007-10-14 07:10:57 UTC

2007-10-14  Hiroyuki Ikezoe  <>

        ** Fixes part of bug #258374

        * gtkhtml.c: Rewrite copy-and-paste handling with GtkClipboard instead
        of selection_XX event.
Comment 28 Hiroyuki Ikezoe 2007-10-14 07:16:39 UTC
I made a simple test program without bonobo. The issue of clipboard text disappearance does not happen on the test program only if the program exits harmlessly.

I think the issue is caused by bonobo or related codes.
Comment 29 Hiroyuki Ikezoe 2007-10-14 07:17:12 UTC
Created attachment 97195 [details]
simple test program
Comment 30 Sebastien Bacher 2007-10-30 18:09:33 UTC
Looks like the changes break the ABI, 3.17.1 dropped the gtk_html_request_paste without changing the soname
Comment 31 Srinivasa Ragavan 2007-10-30 18:32:33 UTC
Hiroyuki, can you re patch this in a way we don't break it? I would like to see this function still there implemented. The last thing we should do is break it if no way it is possible.
Comment 32 Thomas Wood 2007-11-19 10:52:19 UTC
*** Bug 463066 has been marked as a duplicate of this bug. ***
Comment 33 Oxmosys 2008-01-17 15:35:23 UTC
A lot of programs does have this bug which is most of time related to a recent change in FreeDesktop Clipboard Manager specification. Perhaps that this is what you need to fix this bug :
Comment 34 Matthew Barnes 2008-03-11 01:04:02 UTC
Bumping version to a stable release.
Comment 35 Akhil Laddha 2008-08-06 05:38:25 UTC
Scenario works fine in current stable 2.22.3. It saves text after closing window and i can paste at other place also. 
Comment 36 Matijs van Zuijlen 2008-08-06 14:36:08 UTC
Yes, the scenario works in Evolution

The clipboard contents is still lost after quiting Evolution, however.
Comment 37 Margarita Manterola 2009-05-28 22:59:50 UTC
*** Bug 410059 has been marked as a duplicate of this bug. ***
Comment 38 Matthew Barnes 2009-11-27 03:14:34 UTC
This is fixed now in 2.29.  Closing as OBSOLETE.
Comment 39 Oxmosys 2009-11-27 04:11:33 UTC
Thanks for your update!