537274 - Clipboard TIMESTAMP broken

Status: NEW

(Core :: DOM: Selection, defect, P5)

Description

[Pierre Ossman]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.6) Gecko/20091216 Fedora/3.5.6-1.fc12 Firefox/3.5.6
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.6) Gecko/20091216 Fedora/3.5.6-1.fc12 Firefox/3.5.6

Mozilla's current clipboard code doesn't follow the ICCCM and therefore has problems interoperating with other X11 applications.

The area where mozilla fails is that the TIMESTAMP target is not properly implemented, but always returns 0. Many applications will interpret this as meaning that the Mozilla application only has old clipboard data and it will often be ignored.

One common set of such applications are terminal server clients. They need to compare the time of the local clipboard with that of the server and determine which is the newest.

Another class are those that wish to merge PRIMARY and CLIPBOARD intelligently, generally to be compatible with a system that does not have multiple clipboard buffers. Again, this requires a valid timestamp to determine which to use.

This is a required target and the meaning is very well defined in the ICCCM, so there is no doubt that this is a bug.

Reproducible: Always

Comment 1

[David Fries]

Attachment: instead of current time, use an event time

This patch is against iceweasel (firefox) 3.5.9, here is a fix for 3.5.9,
the code in question was replaced in,
Bug 311340 - "Clipboard data is lost on exit (Should implement the
freedesktop.org specification for clipboard management)" [r=karlt]

Firefox is calling gtk_selection_owner_set() with GDK_CURRENT_TIME
(which is 0L, same as Xlib CurrentTime), which violates ICCC rules for
SetSelectionOwner which gtk_selection_owner_set calls (included
below).  There are two problems with violating ICCC, getting the
selection out of order and the bigger one of getting the timestamp
of when the selection was acquired.

Using CurrentTime (current X server time when it processes the
request), Firefox can get the selection out of order.  To make a
repeatable demonstration, select some text in firefox, `killall -STOP
firefox-bin`, press Control-C to the now unresponsive firefox window,
select and copy some text in another program to the clipboard, paste
from the clipboard, run `killall -CONT firefox-bin`, firefox receives
the Control-C and gets the selection, and paste again.  The result is
the firefox buffer, but that is out of order, the other program had
the request to copy to the clipboard after firefox.  It's probably not
that often that firefox is run over a high latency network link or it
is just not responsive enough that this would be visible to a user,
but still it is incorrect behavior.

The other problem with using CurrentTime 0, is that gtk/gdk uses that
time value later when another client queries firefox with a TIMESTAMP
to find out when firefox acquired the selection.  There are programs
which query both primary and clipboard and take the selection that is
newest and 0 always looses causing the user to not be able to get the
firefox selection, or depending on the comparison it could always take
the clipboard in case of a tie and get the newer selected text.  This
can be frustrating and non-obvious when you keep getting what should
be old selection data on such clients.

Using gtk_get_current_event_time() instead of GDK_CURRENT_TIME fixes
both problems.

Quoting from "Inter-Client Communications Conventions Manual" Version 2.0

SetSelectionOwner

The client should set the specified selection to the atom that
represents the selection, set the specified owner to some window that
the client created, and set the specified time to some time between
the current last-change time of the selection concerned and the
current server time. This time value usually will be obtained from the
timestamp of the event that triggers the acquisition of the selection.
Clients should not set the time value to CurrentTime, because if they
do so, they have no way of finding when they gained ownership of the
selection. Clients must use a window they created so that requestors
can route events to the owner of the selection.

                                              Convention
       Clients attempting to acquire a selection must set the time
       value of the SetSelectionOwner request to the timestamp of the
       event triggering the acquisition attempt, not to CurrentTime. A
       zero-length append to a property is a way to obtain a timestamp
       for this purpose; the timestamp is in the corresponding
       PropertyNotify event.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Red Hat bug for that - https://bugzilla.redhat.com/show_bug.cgi?id=596748

Comment 3

[Martin Stránský [:stransky] (ni? me)]

The selections are no more used in clipboard code, we use gtk_clipboard_set_with_data() now which should fix the timestamp issue.

Comment 4

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.