History must be cleared twice to be fully cleared

Bug #1368499 reported by jpfle
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Xfce4 Clipman Plugin
Confirmed
Medium
xfce4-clipman-plugin (Ubuntu)
Triaged
Undecided
Unassigned

Bug Description

Steps for 1 item in the history
===============================

Say the clipboard is empty.

1) Copy with "Ctrl+C" some text from any software (for example gedit). There's now 1 item in the clipboard history.

2) Click on the clipman icon on the panel and choose "Clear".

Result: the item is not cleared, so there's still 1 item in the history.

3) Click again on the clipman icon on the panel and choose "Clear".

Result: the history is now cleared. No item remains.

Steps for several items in the history
======================================

Say the clipboard is empty.

1) Copy with "Ctrl+C" some text from any software (for example gedit). There's now 1 item in the clipboard history.

2) Copy again with "Ctrl+C" some text. There's now 2 items in the history.

3) Copy again with "Ctrl+C" some text. There's now 3 items in the history.

4) Click on the clipman icon on the panel and choose "Clear".

Result: the first two items are cleared, but the last one remains, so there's still 1 item in the history.

5) Click again on the clipman icon on the panel and choose "Clear".

Result: the history is now cleared. No item remains.

More information
================

- xfce4-clipman-plugin 1.2.6

- In the preferences, I checked "Store last copied image", "Ignore selections" and "Reorder history items". All other checkboxes are unchecked. I also have "Size of the history: 10" and "Paste instantly: None".

- Xubuntu 14.10 Beta 1 (64-bit)

- Note that I didn't have this bug with xfce4-clipman-plugin 1.2.5 on Xubuntu 14.04.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: xfce4-clipman-plugin 2:1.2.6-1
ProcVersionSignature: Ubuntu 3.16.0-14.20-generic 3.16.2
Uname: Linux 3.16.0-14-generic x86_64
ApportVersion: 2.14.7-0ubuntu2
Architecture: amd64
CurrentDesktop: XFCE
Date: Thu Sep 11 22:30:30 2014
InstallationDate: Installed on 2012-10-09 (702 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
SourcePackage: xfce4-clipman-plugin
UpgradeStatus: Upgraded to utopic on 2014-08-29 (13 days ago)

Revision history for this message
In , jpfle (jpfle) wrote :

Steps for 1 item in the history
===============================

Say the clipboard is empty.

1) Copy with "Ctrl+C" some text from any software (for example gedit). There's now 1 item in the clipboard history.

2) Click on the clipman icon on the panel and choose "Clear".

Result: the item is not cleared, so there's still 1 item in the history.

3) Click again on the clipman icon on the panel and choose "Clear".

Result: the history is now cleared. No item remains.

Steps for several items in the history
======================================

Say the clipboard is empty.

1) Copy with "Ctrl+C" some text from any software (for example gedit). There's now 1 item in the clipboard history.

2) Copy again with "Ctrl+C" some text. There's now 2 items in the history.

3) Copy again with "Ctrl+C" some text. There's now 3 items in the history.

4) Click on the clipman icon on the panel and choose "Clear".

Result: the first two items are cleared, but the last one remains, so there's still 1 item in the history.

5) Click again on the clipman icon on the panel and choose "Clear".

Result: the history is now cleared. No item remains.

More information
================

- xfce4-clipman-plugin 1.2.6

- In the preferences, I checked "Store last copied image", "Ignore selections" and "Reorder history items". All other checkboxes are unchecked. I also have "Size of the history: 10" and "Paste instantly: None".

- Xubuntu 14.10 Beta 1 (64-bit)

- Note that I didn't have this bug with xfce4-clipman-plugin 1.2.5 on Xubuntu 14.04.

Revision history for this message
jpfle (jpfle) wrote :
Changed in xfce4-clipman-plugin:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , jpfle (jpfle) wrote :

I can't reproduce the bug since a recent update.

Revision history for this message
jpfle (jpfle) wrote :

I can't reproduce the bug since a recent update.

Changed in xfce4-clipman-plugin (Ubuntu):
status: New → Invalid
Changed in xfce4-clipman-plugin:
status: Confirmed → Invalid
Revision history for this message
In , jpfle (jpfle) wrote :

Actually, it's still reproducible. I reopen the report.

Revision history for this message
jpfle (jpfle) wrote :

Actually, it's still reproducible. I reopen the report.

Changed in xfce4-clipman-plugin (Ubuntu):
status: Invalid → New
Changed in xfce4-clipman-plugin:
status: Invalid → Confirmed
Revision history for this message
In , Maybespamforandy1 (maybespamforandy1) wrote :

I am consistently having this issue on xubuntu 14.04 and clipman 1.2.5 on my desktop/workstation. The only comment to add is that after about 1 hour of copying something, I don't need to do the double clear.

On this same system (before I upgraded to xubuntu 14.04) when running xubuntu 13.04, I almost always could never get the last clipboard item to clear. Before I was running xubuntu 13.04 (don't remember what that previous version was), I didn't have this problem much.

I'm not sure if there could be some other program interacting with the clipboard that is triggering this to happen. This system was originally installed as ubuntu, but I switched it over to xubuntu after unity came out and I think I've removed most gnome and unity desktop packages by now.

On my laptop, which also has xubuntu 14.04 and clipman 1.2.5 I have never had this problem once. This system had a fresh install of xubuntu 14.04 .

Revision history for this message
In , Bugzilla-xfce-org (bugzilla-xfce-org) wrote :

It looks like I just fixed this for my setup...

I *think* I first noticed it after upgrading Fedora 23 to Fedora 24 using 'dnf system-upgrade', but there is a chance that it was already happening without my having noticed it.

System is a fully updated Fedora 24 that was a fresh install of F21 but has been upgraded without any skips to the current 24.

My fix:

1. Add a second copy of Clipman to the panel.
2. Test by adding a few items and confirm that they show in both old and new instance.
3. Clean using the new instance and then notice that all items were cleared from it.
4. Also notice that the first instance did not have those same items cleared.
5. Removed the first instance and move the new one into that position.
6. Confirm that a single clear now works as expected.

I will return and update if the issue returns; but note that I have not rebooted yet to give it a proper test.

Revision history for this message
In , Maybespamforandy1 (maybespamforandy1) wrote :

I tried what you have said, but I cannot add two instances of clipman to the panel. If I already have one in there, then the clipman is greyed out in the "Add New Items" window and if I try to drag it to the panel anyway, it just drags an X icon and then disappears when I leg go of the mouse button.

I am using Ubuntu 14.04.4

Revision history for this message
In , Bugzilla-xfce-org (bugzilla-xfce-org) wrote :

Andy: Have you tried to see if you can remove and reinstall clipman from the panel?

Revision history for this message
In , Maybespamforandy1 (maybespamforandy1) wrote :

I can remove and then re-add clipman from the panel, but never add a second one without removing the first. Removing and re-adding does not fix the problem.

Revision history for this message
In , Simon Steinbeiß (ochosi) wrote :

Could you try 1.4.0 and see whether you can reproduce the problem?

Revision history for this message
In , Rinat (ibragimovrinat) wrote :

Hi. I see this behavior too, with both 1.4.0 and latest version
from git repository. But only sometimes.

I tried to add printf-like tracing to figure out what
happens. And it looks like clear command does what it should, it
clears list. But then "owner-changed" signal is triggered. It
then causes clipman to read data from clipboard and insert it
into the history.

I don't have detailed understanding of what happens, but since
Xlib selection API is asynchronous, it has to be asynchronous in
GTK+ too. And perhaps, some interference between
gtk_clipboard_set_text() and gtk_clipboard_clear() happens which
causes X application to keep its selection, which is then echoes
back into clipman.

Revision history for this message
In , Rinat (ibragimovrinat) wrote :

Created attachment 6894
Avoid calling gtk_clipboard_clear()

I think there is no sense in calling gtk_clipboard_clear() after
gtk_clipboard_set_text(). Latter makes a copy of data, and sets
required reply callback, so other applications will get an empty
string which is fine. Calling _clear() makes GTK+ to call
XSetSelectionOwner() with owner=None, which may cause change of
selection owner with "strikeback" effect.

Also passing length of 1 looks wrong. String is empty, so its
length should be 0. Luckily, GTK+ uses g_strndup() inside, which
makes it an empty string rather than a string of one '\0'.

This patch fixes issue for me. I could reproduce it before the
patch, and can't reproduce after.

Revision history for this message
In , Simon Steinbeiß (ochosi) wrote :

@Rinat: Hey this sounds plausible and your patch seems very straightforward. However I'd like to be able to reproduce this in order to verify the patch before pushing it into the next release. Can you give some instructions as to how to get to this erroneous behavior?

Revision history for this message
In , Rinat (ibragimovrinat) wrote :

(In reply to Simon Steinbeiss from comment #11)
> Can you give some instructions as to how to get to this erroneous behavior?

It's irregular.

At the moment, I can open text editor (Geany in my case), make some random
keystrokes, then copy text multiple times. Select, Ctrl-C, select another,
Ctrl-C. Then click on clipman icon (I use systray version), select
"clear history". It makes all item except one disappear. After I click
"clear history" second time, that last item disappears too.

But half an hour ago I did the same steps, and history was cleared
at a heat.

Revision history for this message
In , Rinat (ibragimovrinat) wrote :

(In reply to Simon Steinbeiss from comment #11)

I've got an idea. Since I believe the issue is kind of race
condition, it's worth to try to add delays to make it apparent.
For example, to insert "sleep(1)" at the end of
cb_clear_history().

Revision history for this message
In , Simon Steinbeiß (ochosi) wrote :

@Rinat: Ok, let us know how it goes! Sorry that I haven't found the time to reproduce the issue so far.

Revision history for this message
In , Rinat (ibragimovrinat) wrote :

(In reply to Simon Steinbeiss from comment #14)
> @Rinat: Ok, let us know how it goes! Sorry that I haven't found the time to
> reproduce the issue so far.

Actually, this was supposed for you to try :-)

You said earlier that you need a way to reproduce the issue to make
sure that proposed patch actually fixes it. So that's what I came up
with, delays. I have no problems reproducing issue on my machine
lately, so can't tell whenever it helps to reveal it or not.

I thought it's easier to add a "sleep(1);" line manually than
to apply patch. But anyway, here it is:

------------
diff --git a/panel-plugin/menu.c b/panel-plugin/menu.c
index 0f24fa7..d682a6a 100644
--- a/panel-plugin/menu.c
+++ b/panel-plugin/menu.c
@@ -264,6 +264,7 @@ cb_clear_history (ClipmanMenu *menu)
   clipboard = gtk_clipboard_get (GDK_SELECTION_PRIMARY);
   gtk_clipboard_set_text (clipboard, "", 1);
   gtk_clipboard_clear (clipboard);
+ sleep(1);
 }

 /*
------------

Revision history for this message
In , Simon Steinbeiß (ochosi) wrote :

Sorry for the misunderstanding, of course I could've added the sleep myself. I thought you wanted to find a sleep that makes this more reproducible.

I've now cleared my history for about 10 minutes and it always worked (with the panel plugin though)...

Revision history for this message
In , Rinat (ibragimovrinat) wrote :

Today I tried one more time. And now can't reproduce it,
with or without added "sleep(1);". So, that method
doesn't work. I doubt I'll be able to find another way,
but I'll try.

Revision history for this message
In , Simon Steinbeiß (ochosi) wrote :

I'm wondering if the problem described here appears if the mouse selection is also stored in the history (uncheck "Ignore mouse selections" in the history tab in 1.6.x).

Revision history for this message
In , Gentoo-eshoes (gentoo-eshoes) wrote :

Currently (1.6.1) if "Remember history" was on, and you enter settings and switch it to off, then [Close], the file in which history is stored ie. ~/.cache/xfce4/clipman/textsrc remains intact until the next time something is copied into clipboard.

Similarly if the setting is turned on, the file is created only next time something is copied.

(just pasting without copying first, has no effect on the file)

Revision history for this message
In , Simon Steinbeiß (ochosi) wrote :

I guess the history could be cleared/stored upon changing that setting, but that's really not the problem originally described in this bugreport.

Revision history for this message
In , Gentoo-eshoes (gentoo-eshoes) wrote :

(In reply to Simon Steinbeiss from comment #20)
> but
> that's really not the problem originally described in this bugreport.

oh crp, you're right! forget I said anything. Sorry for the noise.

Revision history for this message
Sean Davis (bluesabre) wrote :
Changed in xfce4-clipman-plugin (Ubuntu):
status: New → Confirmed
Sean Davis (bluesabre)
Changed in xfce4-clipman-plugin (Ubuntu):
status: Confirmed → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.