User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.8a4) Gecko/20040916 Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.8a4) Gecko/20040916 When one selects something (e.g. a URL) in Mozilla, quits it and try to paste the selection to another Mozilla, one gets nothing. Reproducible: Always Steps to Reproduce: 1. Start Mozilla. 2. Select a URL from this Mozilla instance (e.g. with Copy Link Location). 3. Quit Mozilla. 4. Restart Mozilla. 5. Remove the current URL (e.g. with Ctrl-U). 6. Click with the middle button over the location bar. Actual Results: One gets nothing. Expected Results: The URL should be pasted.
this is how the clipboard on linux works - you can only paste when the app you copied from is still running. http://members.chello.nl/~h.lai/gnome-clipboard-daemon/ may be helpful to you (I don't know the program - random google hit)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
> this is how the clipboard on linux works - you can only paste when the app you > copied from is still running. This is wrong. Try with xterm or emacs. Even if the application no longer runs, it is still possible to paste the old selection.
ok, I just tried with xterm. I started xterm, entered and selected some text. I verified that I could paste while xterm was running. I then closed xterm by hitting ctrl+d. xterm closed. hitting the midddle mouse button then didn't do anything.
On my machine (with the official xterm), it works. Someone reported the same problem as you in the French Debian mailing-list a few days ago and it appeared that he didn't have the Debian xterm installed; I asked him more information, but didn't get a reply. So, I think that you're using a wrong xterm (here, "xterm -version" outputs "XTerm(196)"). Could you try with Emacs too? Perhaps it isn't possible on your machine, but as it works on mine (note: I don't use a desktop environment such as GNOME or KDE, I just have the fvwm2 window manager), it should also work with Mozilla too.
my xterm is: XFree86 22.214.171.1243(184) but I can't imagine that xterm is the fault here. The way X c&p works just does not allow pasting after the app is closed. maybe you have some clipboard daemon running? > Could you try with Emacs too? sorry, don't have it installed
> but I can't imagine that xterm is the fault here. The way X c&p works just does > not allow pasting after the app is closed. AFAIK, the selection is attached to the root window or something like that, thus it is not lost. > maybe you have some clipboard daemon running? No, no clipboard daemon.
BTW, do you have xclip installed? You can try: echo -n blah | xclip Though xclip is no longer running, it is still possible to paste the selection (fortunately, otherwise xclip would be completely useless).
Hmm... xclip is still running but detached from the terminal, and it quits as soon as another application takes ownership of the selection. Mozilla could do the same thing. However, when I quit xterm and check that it is no longer running, its selection is still available.
don't have xclip... hm ok, moving this to gfx:gtk to see whether we can do what xterm does...
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
14 years ago
Assignee: selection → blizzard
Component: Selection → GFX: Gtk
QA Contact: ian
xterm uses CUT_BUFFER0, which has been deprecated for years. Mozilla does not use it; see the bugs on it (some of them WONTFIX). Comment 1 is correct -- PRIMARY is cleared when the application holding it quits. If you want the data to persist, use CLIPBOARD (eg hit Ctrl-C). PRIMARY is more like drag-and-drop than copy/paste, and you woudln't expect to drag from an application you've quit, now would you?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago → 14 years ago
Resolution: --- → INVALID
> If you want the data to persist, use CLIPBOARD (eg hit Ctrl-C). But this needs an additional key sequence. Why wouldn't there be an option to automatically copy the PRIMARY selection to CLIPBOARD (some kind of "auto-copy" feature)? Having two kinds of selections is quite confusing, IMHO.
I'm not sure, but perhaps I'm affected by bug 160200 (I've checked that clipboard.autocopy was set to true). But it is declared as a Windows XP bug.
> Why wouldn't there be an option to automatically copy the PRIMARY selection to > CLIPBOARD Taking PRIMARY does not require sending all the data to the server, while putting data on CLIPBOARD does.... So automatically putting every selection in CLIPBOARD could be a little performance-intensive. > Having two kinds of selections is quite confusing, IMHO. Take that up with the X folks. That's just the way X works. Note that there are not two types of selections, just two things you can do with a selection once you have one. It's interesting that you're complaining about having two things you can do with the selection but also wanting the xterm behavior (where the selection ends up in PRIMARY _and_ maybe in the cut buffers _and_ maybe in CLIPBOARD depending on what you do)... And no, bug 160200 is not relevant.
> So automatically putting every selection in CLIPBOARD could be a little > performance-intensive. This is wrong. At least with CUT_BUFFER0, this has always been immediate: I've never noticed any performance problem related to the selections with xterm and emacs. So, why wouldn't it be the same for CLIPBOARD? If other users dislike that, they could just disable the option. > It's interesting that you're complaining about having two things you can do > with the selection but also wanting the xterm behavior (where the selection > ends up in PRIMARY _and_ maybe in the cut buffers _and_ maybe in CLIPBOARD > depending on what you do)... The xterm behavior is self-consistent. When dealing with xterms, only the last selection is taken into account; the user doesn't even notice that there are CUT_BUFFER0, PRIMARY and CLIPBOARD.
> At least with CUT_BUFFER0, this has always been immediate: I've > never noticed any performance problem Try selecting a bunch of text over a slow link when running mozilla over remote X. > The xterm behavior is self-consistent. When dealing with xterms, only the last > selection is taken into account; Not if you use xterm with other apps (eg try selecting in xterm, quitting the xterm, then pasting in a modern GTK app).
> Try selecting a bunch of text over a slow link when running mozilla over > remote X. I never do that, so this is not my problem. This is just like saying that Mozilla shouldn't support colors because this would decrease performance over a slow link. > Not if you use xterm with other apps This is not a problem with xterm, but with these other apps.
BTW, I've tried with "Copy" in a Mozilla, quit it, and tried to paste the old selection to another Mozilla with the middle button ("Paste" in the contextual menu was greyed out), and it didn't work.
> This is just like saying that Mozilla shouldn't support colors because this > would decrease performance over a slow link. No, this is like saying that Mozilla shouldn't do colors in the slowest way it can think of. > This is not a problem with xterm, but with these other apps. Sorry, this is false. Please do a little bit of research on the way the clipboard works in X. The fact is, there is general agreement how modern apps should behave, and xterm simply doesn't behave as expected. I'm done with this bug. If you want to use a window system with a different clipboard model from X, then please do so. Or take the clipboad model up with the folks writing the X protocol specifications and the like.
Anyway, comment 10 is wrong: even if I use the clipboard (explicit copy/paste), data don't persist after the application quits. I think this is what had been discussed here, in particular: http://mail.gnome.org/archives/desktop-devel-list/2004-April/msg00335.html This is regarded by most people as a bug and should be fixed. One of the suggestions (provided by the library, e.g. GTK) is that the application doesn't really quit as long as it owns the selection; as said, the application would just end all interactive abilities. Now, concerning the PRIMARY selection, I think that data should persit too, even if you regard PRIMARY as drag-and-drop. Let's take an example showing that data should persist in a drag-and-drop. For instance, you may have configured an application to quit automatically when it has finished its job. Suppose that you initiate a drag-and-drop, and before the drag-and-drop is done, the application finished its job and wants to quit. Then one shouldn't expect that the drag-and-drop terminates because of that, before the user could drop the selection, i.e. the application (or at least a part of it) should wait for the selection drop if the data were not put somewhere else before. Setting a PRIMARY selection is like initiating a drag-and-drop which would end when the PRIMARY selection changes. Another point is that the user shouldn't be aware of the concept of application process or thread or whatever, in particular for communication protocols between applications. I mean that the user should be able to see as few differences as possible between a Mozilla process having two windows and two Mozilla processes each having one window (well, with Mozilla, this is a bit particular as two Mozilla processes can't share the same profile, but with other applications, such as gnome-terminal, this would be even more confusing).
You need to log in before you can comment on or make changes to this bug.