From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 Epiphany/1.4.4 Description of problem: The clipboard is a holding area for moving simple data between applications. 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): How reproducible: Always Steps to Reproduce: x Additional info:
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 window. 3. With Evolution still open, try and use that copied text anywhere else. You can't.
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 everything else.
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 fedora-list 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. To reproduce: 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".
*sigh* 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 bug report. 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 xorg. 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 AND_IT_MIGHT_BE_REDHAT. ;o)
Okay! redhat.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WONTFIX |SOMEONE_WILLFIX_ |THIS_PROBLEM_IN_ |FUTURE_XORG_RELEASE |AND_IT_MIGHT_BE_ |REDHAT
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)