Closed Bug 63419 Opened 25 years ago Closed 21 years ago

Pasting in X should use cut buffer 0 if there is no selection

Categories

(Core :: DOM: Selection, defect)

Product:
Core
Component:
DOM: Selection
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: bzbarsky, Assigned: pavlov)

References

Details

(Keywords: helpwanted)

Currently, if there is no active selection pasting into Mozilla does nothing. This is inconsistent with other X programs, which will examine cut buffer 0 if the selection is empty and use data found in that (if any). Mozilla should also use cut buffer 0 if the selection is empty. This bug is related to bug 37057. Also, if this is implemented Mozilla should clear the X selection when the visual Mozilla selection is cleared. See news://news.mozilla.org/8o9928$5su3@secnews.netscape.com for a detailed discussion of the issues involved. I am marking severity as normal, because while this is just a look and feel issue I am far too often left wondering why my attempted paste into Mozilla failed.
ccing pavlov since this is X selection stuff.
assigning to pav
Assignee: mjudge → pavlov
Target Milestone: --- → Future
Yes, please look at this; i've written a patch for screen (www.gnu.org/software/screen/) that throws its paste buffer selection into X's copy buffer 0, mainly because i often have to paste data into forms from an xterm, and screen's scrollback buffer defeats xterm's. However, due to this bug, i still can't paste into mozilla. Most annoying. And writing a fork-and-serve-selection routine into screen would *definitely* be overkill...
*** Bug 117642 has been marked as a duplicate of this bug. ***
real-life use case (from bug 117624): Steps to Reproduce: 1.IRC with terminal client, copy an URL 2.wait until someone says something and "paint" vanishes 3.try to paste the URL into browser 4.get annoyed, iterate steps 1-3 until you are faster than other people and finally succeed. Actual Results: Finally I am faster or then I just open another xterm and paste the URL in there, and from there to browser. Expected Results: Accepted the pasting attempt as nobly as xterm does.
Keywords: helpwanted, nsbeta1
QA Contact: blaker → tpreston
per adt, not critical for nsbeta1. hence minus.
Keywords: nsbeta1 → nsbeta1-
Blocks: 144260
*** Bug 208635 has been marked as a duplicate of this bug. ***
Boris: I think your gripe is actually with your IRC client, who should not be disowning the selection just because new text showed up below it.
Yeah, indeed. Upon sober reflection, I really don't care about this.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
But other people do care. This is an extremely annoying problem and happens in situations having nothing to do with IRC. I can't imagine it would take that long to fix for someone who already knows the codebase (unfortunately, I don't). Could someone please reopen this bug?
The point isn't so much that this _can't_ be "fixed"; the point is that it shouldn't be. And given that there is no one who knows the codebase in the area involved, last I checked, it's doubtful that it even could be.
I also do care very much, as the current selection often disappears before I could paste it to Mozilla.
> I also do care very much, as the current selection often disappears before I > could paste it to Mozilla. What program are you using that does this?
xterm (it has always worked like this). This happens in any of the following cases after selecting something: 1) I select something in the index in Mutt (running in an xterm), then go to the pager (e.g. by reading a message). 2) With screen (running in an xterm): I select something and switch to another screen window. 3) I click on the left button in the xterm (this makes the selection disappear). 4) I quit the xterm. There are many other examples similar to the first two points, with curses-based applications running in xterm. For points 1, 2, 3, other terminals like rxvt and gnome-terminal do not have this problem with copy-paste to Mozilla. But point 4 is not specific to xterm. I often want to paste selections quite late after doing the selection as this is sometimes more practical and also because Mozilla takes a lot of memory (currently: 101MB res., 44MB shared) and it may need several dozens of seconds to "wake up" due to the swap. Moreover I sometimes need to wait for a page to be loaded, in order to paste the text to a form on such a page.
You will care about this a lot less once you stop using xterm and start using something a decade or two less obsolete like, well, anything else. For example, gnome-terminal. xterm is completely unmaintained; I don't know why they even ship it any more.
gnome-terminal takes 40 seconds to start up! Also, I can't adjust the selection with the right button. xterm is fast and does exactly what I want.
Here's a nickel, buy a computer made in this decade too. xterm clearly doesn't do what you want, because one of the things you want is "don't toss the selection just because some more text was printed."
> Here's a nickel, buy a computer made in this decade too. Silly remark. My computer is a PowerBook G4. > xterm clearly doesn't do what you want, because one of the things you want is > "don't toss the selection just because some more text was printed." xterm works perfectly well with other applications (and with itself). This is not the case of Mozilla where a copy-paste from a Mozilla instance to another Mozilla instance doesn't always work. This is completely ****!
yes indeed it works with gnome-terminal. but xterm is the reference implementation. and: 8910 willi 15 0 31864 12m 17m S 3.0 5.1 0:03.61 gnome-terminal 2422 willi 16 0 8476 3936 6788 S 0.0 1.5 0:01.98 xterm -ls -fg orange -bg black -bd red -cr yellow -ms yellow which is a huge difference, if this aplies: ps aux |grep xterm |wc -l 17 and this is a fresh session. applications having problems with the cutnpaste would include irssi and top. allso i do have often the problems that <shift>+<insert> gives a different cutnpaste selection than <middlemousebutton> which is really anoying.
And people should stop thinking that memory and disk space are cheap. On Debian, gnome-terminal requires 35 MB disk space! One of my machines is short of space and I couldn't install it (remember that gnome-terminal is not the only application to take disk space). Also I doubt that many people use gnome-terminal on their Zaurus (for those who installed pdaxrom) when there is a cheaper alternative. But anyway, this bug should be fixed at least to make copy-paste between two Mozilla applications work in any case. And if one of you has enough arguments against xterm selection mechanism, there's Debian bug 276090.
Vincent: There aren't any arguments. Just excuses by "hackers": http://invisible-island.net/personal/hackers.html So it's unlikely that your problem will be resolved. I use mozilla as a last resort anyway - recommend opera.
Thomas: I've tried with Opera 7.11 and 7.54 and this doesn't work with them either.
I didn't know anything about cut buffers and primary selections until just recently, when I found something I had been looking for a long time: wxcopy, a command line program that can copy text from stdin into X's cut buffer. I thought this would finally make it easy to edit large amounts of text in a real text editor, and paste it into Mozilla's forms. But of course, that didn't work since only primary selections can be pasted into Mozilla. Since the wxcopy program is clearly an essential tool, there must be others like it that _do_ work with Mozilla. What do other people use? (FYI: I only use text based/console editors; I don't have a single KDE or Gnome file installed, and I intend to keep it that way.)
Nevermind, I found a program that seems to work: xselection.
Haakon: concerning what you want to do, perhaps xclip (command line interface to X selections) or the mozex XPI (can start an editor when one wants to edit a form) could be useful.
> since only primary selections can be pasted into Mozilla That's not true. CLIPBOARD can be pasted as well (Ctrl-c).
Copy-pasting CLIPBOARD didn't work at that time (even between two Mozilla's). This seems to be fixed. But it needs Ctrl-V; could there be an option so that the middle-button pastes the clipboard instead of having to type Ctrl-V? (Ditto for Mac OS X.)
No, middle button should absolutely not paste the CLIPBOARD.
> No, middle button should absolutely not paste the CLIPBOARD. Is there any reason?
Yes. It'd be incredibly confusing. Middle-button should insert whatever is currently selected; nothing more and nothing less.
> Yes. It'd be incredibly confusing. I don't find this confusing. > Middle-button should insert whatever is currently selected; nothing more and nothing less. First, Mozilla doesn't behave in that way (for instance, select something on a web page, close the tab so that nothing is currently selected any longer, then you can still paste the old selection with the middle button). So, your argument is void (unless you see the current behavior as a bug, but many users would not be pleased if this changed). Second, users should be able to do any mouse or key binding they want.
> First, Mozilla doesn't behave in that way That's a longstanding bug I'd pay people to fix. It's been filed for years. > Second, users should be able to do any mouse or key binding they want. Sure. If they change their general "paste PRIMARY" binding for the OS, we should follow that. But whatever we do, we should be following the OS behavior here.
This is not an OS thing. Perhaps something at the GTK+ level (such as the bindings for text editing, and there may be something to add to my .gtkrc-2.0 file). But you should also note that Firefox has its own bindings, inconsistent with the other applications. For instance, "Close Tab" is done with Ctrl+W, whereas in gnome-terminal and in xfce4-terminal, it is done with Shift+Ctrl+W.
> This is not an OS thing. Clipboard interaction? Sure it is. > For instance, "Close Tab" is done with Ctrl+W There was no consistency about "Close Tab" when this binding was implemented. There's a great deal of consistency about how PRIMARY should be handled.
> Clipboard interaction? Sure it is. The protocol is an OS thing, but not the bindings, which are provided by the applications. Cut buffers are also part of the X protocols, and I don't see them in Firefox... > There's a great deal of consistency about how PRIMARY should be handled. No. The fact that the primary selection is kept after it disappears depends on the application. Firefox: kept (but you said this was a bug) gnome-terminal: kept Liferea: discarded Straw: discarded xterm: discarded (but not the cut buffer -> internal inconsistency) xfce4-terminal: kept Opera: kept Gnumeric: discarded Emacs: kept
Vincent: see http://standards.freedesktop.org/clipboards-spec/clipboards-0.1.txt It's a de-facto standard. Changing what middle-mouse-click does (by default) is undesirable, though I'm all for customizability.
It's not a standard, but guidelines (this is the term that is given in the document). Anyway, I don't mind if applications follow these guidelines by default. I recall that I was just asking for an *option* to change the default behavior. Another point is that the authors of the document seem to think that only cut buffers have drawbacks. This is not true. Each method has drawbacks (Primary selection: is often discarded in practice, even when the user hasn't selected anything else since; Clipboard: needs additional operations from the user, hence wastes time), and there are some cases where cut buffers work better than the other methods (e.g. fast copy-paste of a URL, and cut buffers work well for that). Concerning the visibility of a selection, there is an inconsistency between terminal-based and window-based applications when scrolling so that the selection is no longer visible. The terminal-based applications such as xterm discard the selection when scrolling, e.g. in "less". But the window-based applications never discard it when scrolling.
I also forgot: there's the "Copy Link Location" from the menu, that copies the URL to the primary selection instead of the clipboard. IMHO, this is completely inintuitive (but more useful in practice, at least for me).
> that copies the URL to the primary selection instead of the clipboard. It copies to both, actually.
You need to log in before you can comment on or make changes to this bug.