Linux: Prevent omnibox autocomplete from stealing the primary X selection.

Linux: Prevent omnibox autocomplete from stealing the primary X selection.

This is mostly accomplished by decoupling autocomplete (and the
auto-select-all when first clicking in the omnibox to focus it) from GTK's
clipboard code.  Before we update the selection marks, I unregister the
clipboard and block the signal from reaching my handler.  Afterwards, I
restore things.

This creates the possibly-odd effect that text can be highlighted both in
the omnibox and in Webkit, assuming that the omnibox text isn't actually
the primary selection.  I think that this is reasonable, but let me know if
you can think of a better way that it should be handled.

To test, I confirmed that all of the cases listed in
http://codereview.chromium.org/151006's description still work, along with
the following new ones:

1. Highlight text in an xterm to make it the primary selection.  Start
   typing an autocomplete-able URL into Chrome's omnibox.  Middle-click in
   the xterm and check that the xterm's text, rather than the autocompleted
   text from the omnibox, is pasted.

2. Now switch to a different tab and middle-click in the xterm again.  The
   xterm's text should still be pasted.

3. Switch to the original tab and check that the xterm's text is still the
   primary selection.

4. Highlight text in an xterm.  Click in Webkit to make sure
   that the omnibox doesn't have the focus.  Left-click in the omnibox.
   Its text should be highlighted but not made the primary selection
   (middle-clicking in the xterm should still paste the xterm's text).

   EDIT: I've changed this behavior -- clicking in the omnibox to focus it
   now sets its text as the primary selection.

5. Now triple-left-click in the omnibox to highlight all of its text.  This
   time, the URL should become the primary selection.

   EDIT: This is no longer relevant.

I noticed the following annoying behavior, but it's also present in the
official build without this change, so I don't think it's a regression
(there's probably something going on in GTK that I don't understand):

Highlight some text in the omnibox to make it the primary selection.
Now double-left-click to highlight a word in an xterm.  The word flashes in
the xterm, but Chrome automatically grabs the selection again.
Double-clicking in the xterm again lets it hang on to the selection.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=21329

[Evan Stade, 2009-07-22 02:49:44]

4. seems wrong to me. The line I've heard about why we highlight the omnibox
when the user clicks it is because the most common user action when clicking in
the omnibox will be to select the text (with the intention of deleting it or
copying it).

If you actually want to put that text on the selection clipboard, you will have
to triple click instead of single clicking. Users won't know to do this though,
so it will just feel broken.

[Dean McNamee, 2009-07-22 16:00:20]

I looked at this.  The whole situation is a bit sad, but I think overall the
code looks ok.  If we decide this is the behavior that we want, I'm ok with it.

On 2009/07/22 02:49:44, Evan Stade wrote:
> 4. seems wrong to me. The line I've heard about why we highlight the omnibox
> when the user clicks it is because the most common user action when clicking
in
> the omnibox will be to select the text (with the intention of deleting it or
> copying it).
> 
> If you actually want to put that text on the selection clipboard, you will
have
> to triple click instead of single clicking. Users won't know to do this
though,
> so it will just feel broken.

[Evan Stade, 2009-07-22 21:53:50]

lgtm, committed r21329