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 523010 - Edit menu selection causes clipboard text retreivel
Edit menu selection causes clipboard text retreivel
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-03-17 17:45 UTC by Ted X Toth
Modified: 2008-10-27 20:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to terminal-window.c (1.17 KB, patch)
2008-03-17 17:46 UTC, Ted X Toth
reviewed Details | Review
patch to terminal-window.c (1.12 KB, patch)
2008-04-10 12:48 UTC, Ted X Toth
none Details | Review
gnome-terminal paste patch (2.41 KB, patch)
2008-04-11 18:58 UTC, Ted X Toth
none Details | Review

Description Ted X Toth 2008-03-17 17:45:13 UTC
Please describe the problem:
Use of gtk_clipboard_request_text in edit_menu_activate_callback causes clipboard text to be retrieved unnecessarily prior to 'Paste' item selection which may never actually occur. Also if 'Paste' is selected the the owner of the clipboard will receive two selection-request-events for the text without a way to differentiate which is the actual paste.

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
This patch replaces the use of gtk_clipboard_request_text with gtk_clipboard_wait_is_text_available when the 'Edit' menu is selected. gtk_clipboard_wait_is_text_available will be a little faster as it doesn't retreive the text and selection  or clipbord managers will only receive one selection-request-event for the data when the 'Paste' occurs if it ever does. Without this change selection-request-event listeners like selection or clipbord managers receive two selection-request-event one when the 'Edit' menu is selected and the other when 'Paste' is selected and there is no way to differnetiate them.


--- gnome-terminal-2.18.4/src/terminal-window.c	2008-03-17 11:30:21.000000000 -0500
+++ gnome-terminal-2.18.4.new/src/terminal-window.c	2008-03-17 11:29:47.000000000 -0500
@@ -753,7 +753,11 @@
 
   window = (TerminalWindow *) user_data;
 
-  gtk_clipboard_request_text (window->priv->clipboard, (GtkClipboardTextReceivedFunc) update_edit_menu, window);
+  if (gtk_clipboard_wait_is_text_available (window->priv->clipboard))
+          update_edit_menu (window->priv->clipboard, "", window);
+  else
+          update_edit_menu (window->priv->clipboard, NULL, window);
+
 }
 
 static void
Comment 1 Ted X Toth 2008-03-17 17:46:42 UTC
Created attachment 107465 [details] [review]
patch to terminal-window.c
Comment 2 Christian Persch 2008-03-17 22:25:23 UTC
Thanks for the patch!

The idea of the patch is right, in that we should only request the targets but not the contents itself. However using blocking API calls in unacceptable; you should use gtk_clipboard_request_contents: with gdk_atom_intern_static_string ("TARGETS") and in the callback test with gtk_target_list_include_text_targets.
Comment 3 Ted X Toth 2008-03-17 22:56:54 UTC
Works for me.
Comment 4 Ted X Toth 2008-03-24 19:19:02 UTC
(In reply to comment #2)
> Thanks for the patch!
> 
> The idea of the patch is right, in that we should only request the targets but
> not the contents itself. However using blocking API calls in unacceptable; you
> should use gtk_clipboard_request_contents: with gdk_atom_intern_static_string
> ("TARGETS") and in the callback test with gtk_target_list_include_text_targets.
> 

Are you going to roll a patch or should I?
Comment 5 Ted X Toth 2008-04-09 20:46:23 UTC
It looks like the latest version 2.22.1 is using gtk_clipboard_request_text which is fine in that it is a non-blocking call but it still retrieves the selection text whenever the edit menu is clicked in order to enable the paste menu item. If paste is selected another retrieval of the selection text is done. It would be better if the the suggestion in comment #2 we're implemented to avoid the dual retrieval and to allow a selection manager to know when the actual paste is occurring.
Comment 6 Ted X Toth 2008-04-10 12:48:43 UTC
Created attachment 108990 [details] [review]
patch to terminal-window.c

Implements solution as described in comment #2.
Comment 7 Ted X Toth 2008-04-11 16:01:05 UTC
It looks like the same issue exists for the right-mouse click menu, where is the code that handles the right-mouse click?
Comment 8 Christian Persch 2008-04-11 16:09:24 UTC
In terminal-window.c on svn trunk.
Comment 9 Ted X Toth 2008-04-11 17:32:12 UTC
The Edit menu and the right click menu are behaving differently. With the patch when I click the Edit menu on the menu bar my selection manager receives a selection-request with target TARGETS as expected. However if I right click the window my selection manager receives a selection-request with target UTF8_STRING before the menu pops up. Any idea what could account for this difference in behaviour?
Comment 10 Christian Persch 2008-04-11 17:49:49 UTC
You mean that even if you also patch screen_show_popup_menu_callback/popup_clipboard_request_callback similarly to your patch here?
Comment 11 Ted X Toth 2008-04-11 18:58:06 UTC
Created attachment 109072 [details] [review]
gnome-terminal paste patch

new version of patch to also handle right click menu
Comment 12 Christian Persch 2008-04-11 21:21:58 UTC
Thanks! I adapted the code to svn trunk, and committed it. 
(In future, please make patches again the svn trunk version instead of a release.)
Comment 13 Ted X Toth 2008-10-27 20:15:47 UTC
This fix is not being applied in version 2.22.2-1, what happened?
Comment 14 Christian Persch 2008-10-27 20:24:22 UTC
This is fixed in 2.24.0; 2.22.x is dead.