Closed Bug 265836 Opened 20 years ago Closed 20 years ago

Can't copy-paste from old mozilla to new mozilla

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
All
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: vincent-moz, Assigned: blizzard)

Details

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
Closed: 20 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 4.3.99.903(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 → ---
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
Closed: 20 years ago → 20 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).
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.