296349 - X needs to also check the "Buffer" - needed so that pasting works better.

Status: VERIFIED WONTFIX

(Firefox :: Shell Integration, defect)

Description

[Ryan King]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

I've been developing Clipboard.pm (http://search.cpan.org/~king), and in doing
so, I've gotten to the root of a bug that has pestered me for years:

Sometimes you can't paste into Firefox (middle click does nothing), but you can
paste into other X programs (e.g., xterm).

As anyone familiar with xlib/nsClipboard.cpp will know, X has a funky
"clipboard" concept.  There are primary, secondary, and clipboard selections.  
Then there's this other thing, the Buffer.  I don't know why it's a separate
concept, but it is.  Any one of those selections could be the one the user
wishes to paste from.*

I whittled down xclip's source to a ~25 line program that dumps the contents of
the Buffer.  It just boils down to a call to XFetchBuffer(), which doesn't need
much more than a Display.

As for where to add the call, I'm not quite sure.  Through experimentation, my
opinion is that the canonical order of importance is: primary, buffer,
clipboard, secondary.  Really, this is up to implementor's preference - as long
as the Buffer gets checked at some point, I'll be thrilled.  Maybe play with the
xclip loop* and see if you can figure out your preference.

* If you're interested in observing these behaviors, try installing xclip and
running the following while you play around:
watch -n1 'for n in primary secondary clipboard buffer; do echo == $n ==; xclip
-o -selection $n; echo; done'

Reproducible: Always

Steps to Reproduce:
1. Open an xterm
2. Highlight something
3. Paste into Firefox.

Ha!  It works.  I tricked you.

Now try:
4. Doing something in the xterm that causes the selection to go away - move the
cursor, single click somewhere, etc.
5. Paste to Firefox.

A practical example: from mutt, highlight a URL, delete the message, and then
don't expect to paste it into Firefox. (Current workaround: paste into xterm,
re-highlight, come back to Firefox)

Comment 1

[Ryan King]

Attachment: Example Usage of XFetchBuffer()

Comment 2

[Elmar Ludwig]

This is probably WONTFIX (cut buffers are not widely supported anyway).

The clipboards-spec from freedesktop.org explains the current behaviour:
http://www.freedesktop.org/wiki/Standards_2fclipboards_2dspec

Comment 3

[Elmar Ludwig]

See also bug 37057 for exporting selection to the cut buffer.

Comment 4

[Ryan King]

(In reply to comment #2)
> http://www.freedesktop.org/wiki/Standards_2fclipboards_2dspec

Well, I decided to do a little more research, and installed every terminal
emulator Debian has.  Turns out the only one that dumps "primary" when the
selection goes away is xterm.  Unfortunately, it's also the most common emulator
out there.

Could "Eat like an elephant, poop like a bird" be used to justify reading from
the cut buffer, but not writing to it?

I guess my personal workaround is going to be to either shoot for an xterm patch
(unlikely success - they're going to be even stingier about patches than
Firefox! ;)) or just finally switch terminals.

Thanks.

Comment 5

[Ryan King]

It looks like, at least on debian, this bug will be fixed upstream.

There is a related bug report, here:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277832

I therefore officially withdraw my request that Mozilla change.

Thanks!