Red Hat Bugzilla – Bug 143262
Clipboard is broken
Last modified: 2007-11-30 17:10:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
The clipboard is a holding area for moving simple data between
The clipboard is emptied when the application providing the copy exits.
We're up to Fedora Core 3 now, we've switched to xorg, and this old
misfeature is still with us.
I can't see a reason for this from the desktop users point of view, so
marking as a bug.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
This is covered in the Fedora Core 3 release notes, in the section
discussing upstream openssh X11 forwarding changes.
Where is the clipboard mentioned?
Here's a good example of breakage:
1. From Evolution, start to write a new e-mail.
2. Copy the body of the message to the clipboard, closing just that
3. With Evolution still open, try and use that copied text anywhere else.
It isn't specific to the clipboard. It is specific to ssh X11
forwarding. If you're experiencing this problem and not using
ssh with X11 forwarding to a remote host, then my assessment
was wrong. In that case, I would suspect the application, not
X, because copy and paste works fine in X.
This is a problem with my local machine, logging into X locally.
Ah, ok. False alarm then. The issue I was refering to is reported
by random people about 1-5 times per day, is not a bug, and is
described in the release notes, and has the same symptoms as what
you described, so I assumed a little bit too much it seems.
Reassigning to "evolution" component, since that is the app you
claim is not working.
Umm.. evolution was given as an example. gedit is broken too, so is
Hmm. In that case you'll need to narrow it down a lot more, because
the clipboard very definitely works for me, and this is the only
"clipboard does not work in FC3 at all in any app" bug report we've
received in bugzilla that was not the result of using applications
remotely over ssh with the default X11 forwarding.
If you need assistance narrowing this down, I suggest using the
email@example.com mailing list. Perhaps your mouse button
is broken even, or perhaps your mouse is misconfigured and the
button isn't working.
Until we can reproduce what you are describing, or have something
solid to go on, there's not a lot we can do. And if only one
single person is reporting the problem, it appears more to be
a local system configuration issue or something at least.
Removing myself from CC, as I am a member of xgl-maint, and don't need
2 copies. ;o)
This isn't a new problem, it's always been broken.
xclipboard was invented for this very reason.
1. Load gedit
2. Type something, copy or cut to clipboard.
3. Close gedit.
4. Try to paste what you copied.
See bug 119759.
Ah, you're not talking about a long time limitation in X itself, and
not a Red Hat specific bug. Not even an X bug at all. It's just
a limitation period.
Since it isn't a bug, but a core part of the design of the X
clipboard, it isn't something that goes away magically by adding
a simple small patch.
In order to "fix" this design limitation, requires designing new
stuff directly into X, which is something that needs to be done
by X.Org in a future X release. Your report should be filed in
X.Org bugzilla, not in Red Hat bugzilla, as it isn't a Red Hat
specific problem, but a generic X11 limitation, however I wouldn't
bother filing a bug in X.Org bugzilla anyway, because this is a
well known limitation that doesn't really need to be tracked in
bugzilla. Various upstream discussions have surfaced to discuss
how to solve this issue in the future, and at some point someone
will likely end up solving it upstream.
Setting bug status to "WONTFIX".
You're joking right? You want to produce a Linux distribution that is
the best for both the corporate server and the corporate desktop
markets, but you'll do _nothing_at_all_ when you find out that the
clipboard doesn't work by design? Try explaining that to a desktop user.
Just because it's an xorg bug, doesn't mean Red Hat have no interest
in it. Or maybe it does.
Red Hat definitely has an interest in seeing the underlying problem
get resolved in X.Org upstream in future releases. Red Hat may
even be who implements the solution down the line.
The issue however is very well known both inside and outside Red Hat
in the X development community, and the proper place to report such
an issue is in the upstream X.Org tracker as it is not vendor
specific. I just don't personally see the value of tracking such
an issue in Red Hat bugzilla however, for several reasons:
1) It will get implemented in due time by X.Org developers (and that
does include Red Hat developers), when there aren't much more
higher priority issues being worked on. Or when someone in the
community volunteers to tackle the problem in light of there being
higher priority issues needing attention.
2) When it's implemented by someone, it probably wont be because
they found a bugzilla report on the issue and determined to hack
out a new X extension to be able to resolve the bug report. More
likely, the people who solve the problem wont have ever seen the
3) Once someone has implemented it, they are unlikely to search
bugzilla to find any possible feature requests about the issue, so
they can close them.
As such, keeping it logged in bugzilla in general, isn't too helpful
in my personal opinion. However, since it is not an OS specific
issue, the proper place if any for to log such an issue is in
the X.Org bugzilla, where it would be seen by multiple OS vendors,
including Red Hat, as well as the rest of the X development community.
Sorry if my previous comments sounded like we're not interested in
the problem. We are very interested in the problem, and in solving
it, but just don't find value in tracking well known long standing
X design flaws like this in our bugzilla.
I believe Owen Taylor or someone else here at Red Hat may have
actually even started implementing an X extension to do this at one
point. The "XFIXES" extension also had some discussion about
possibly adding stuff for this.
The best place for any discussion of it though, is the X.Org
mailing lists, in particular firstname.lastname@example.org.
Sorry for any confusion, but I hope this clarifies things.
Fixing component to xorg-x11 this time for sure. Setting resolution
back to "WONTFIX" as I had to reopen the report to do so. Note that
"WONTFIX" is a poorly worded bugzilla resolution. It doesn't mean
"we don't care, go away". In this case it means "We will not put
a fix for this problem into the operating system release the problem
is reported against, because the fix for this is something that
requires upstream design work which would go into a new Xorg release,
and wont likely ever get released in this version of our OS."
A more appropriate, but non-existant bugzilla resolution which is
more accurate, is SOMEONE_WILLFIX_THIS_PROBLEM_IN_FUTURE_XORG_RELEASE
What |Removed |Added
Hahaha! The email had me wondering if bugzilla had a glitch in
it that allowed that.. until I brought the bug report up. ;o)
That made my day, thanks. ;o)