Hmm, this could conceivably happen if you manage to type
/u and then the s after the entry has completed to /usr/, but
before it has selected the sr/ part. The s would then complete
to /usr/src. 

I am not able to reproduce this here, either my machine is too fast
or I am too slow...

Looks like #309734 describes a similar problem, namely:
"..For example,  
if I want to go to "/usr/bin/" and I just start typing away, I'd end up with  
"/u/sr/bin" or maybe "/usr/bin/in" as the gtkfilesel will autocomplete faster  
then I can type.."
Though it says you need to type slowly enough, not fast. In any case this problem does exist here, and I need to be very careful typing a filename in.

but the autocompletion should not be a problem, since the completion code
matches against the autoinserted part. The following is happening for me
([] indicating autoinserted and selected part)

input      result
/          /
u          /u[sr/]
s          /us[r/]
r          /usr[/]
/          /usr/
s          /usr/s[rc/]
r          /usr/sr[c/]
c          /usr/src[/]

etc

Hm, seems it works fine after ctrl-L is used. So, here are exact steps to reproduce.

1) press Ctrl-O to get Open dialog (say, in gedit)
2) type '/usr' in.

Result: '/usr/src/' in the entry.

If you use ctrl-L, it works fine; if you cancel the entry, and just type after that (but not closing dialog), then it sometimes works right, sometimes doesn't.

*** Bug 309734 has been marked as a duplicate of this bug. ***

What locale are you using?  What's the exact version of GTK+?  I cannot reproduce this with C-l or /

What kind of machine (processor, speed)?

muntyan@mlap:~ $ echo $LANG; echo $LANGUAGE;
en_US
en_US:en_GB:en

No LC* variables set. Debian testing, with gtk-2.8.12. Pentium 4, 2.6GHz.

I'll try gtk-2-8 branch as soon as I have time for building it.

I tried gtk-2-8 branch, same result. Works fine with ctrl-L, breaks when just typing path in.

It has something to do with idiotic clipboard business. I disabled "clear-selection-on-clear-primary-selection", and it works fine. (in gtk-2-8 branch)

Sorry, forgot about details. So, I commented out the gtk_editable_select_region(nothing) in primary_clear_cb, in gtkentry.c.

Here's backtrace of first primary_clear_cb call - I press '/', location dialog appears on the screen, and it stops.

Breakpoint 2, primary_clear_cb (clipboard=0x8684bf0, data=0xb7d6b7f0) at gtkentry.c:3808
3808    {
(gdb) bt

+ Trace 66808

Here's backtrace of second call. If i type "/u" in the FileChooser dialog, then primary_clear_cb is called twice (i put g_print there), so this is it.

Breakpoint 2, primary_clear_cb (clipboard=0x8684bf0, data=0x8755418) at gtkentry.c:3812
3812      g_print ("hi there\n");
(gdb) bt

+ Trace 66810

After adding some debug output, it looks like the following happens:

I type "/u" in, entry inserts "sr/", then it calls gtk_editable_select_region (the inserted text, selection bounds are all correct), but the text doesn't get selected for some reasons. It's not someone stealing the selection, because primary_clear_cb is called *before* gtk_editable_select_region, and not called after that.

What can be a reason for gtk_editable_select_region having no effect (no effect at all, not just selecting and unselecting due to someone else getting selection)?

I tracked it down to gtk_clipboard_set_with_owner() failing in gtk_entry_update_primary_selection() (called from gtk_entry_set_selection_bounds). It fails, then entry calls primary_clear_cb and text unselects.

Created attachment 61410 [details]
test helper

This helps to reproduce what I see here.

See also bug #330565.

See also bug #333319; I'm not sure if it is a duplicate.

*** Bug 333319 has been marked as a duplicate of this bug. ***

I have been able to reproduce this problem in thunderbird under kde now.
The very easy workaround is to just remove the klipper applet from the panel.

(In reply to comment #19)
> I have been able to reproduce this problem in thunderbird under kde now.
> The very easy workaround is to just remove the klipper applet from the panel.

Nope, you've only seen the 100%-reproducable problem with klipper, the one I don't say anything about since nobody gives a shoot to klipper. The bug exists without klipper too, unfortunately. Hardly reproducable, depending on day time and weather, and I don't know what else.

Note that the "easy workaround" means you need to stop using clipboard manager, something which might not be that "easy" (I indeed have stopped using it, exactly because gtk has some strange ideas about how text selection should behave in a modern gui toolkit). You know, another easy workaround is not to use GtkFileChooser. Apparently people indeed use this workaround. "Mouse and nautilus are your friends", "geeks use terminal", and all that.

I can't reproduce this problem anymore with GNOME 2.18 and klipper. I'm using a rather fast computer, so it might be that my computer is too fast. I tried to reproduce this on a virtual machine, but apparently that wasn't slow enough either.

I _can_ confirm this problem here on ArchLinux 686 with Xfce 4.6.0 when klipper is running.

It happend with Firefox in "Choose Helper Application" file dialog after clicking on a link to a file of unknown type and select Open with -> Browse, but i can not reproduce this any more with firefox right now after restarting firefox and klipper.

I can reproduce this with both avidemux2_gtk and mousepad (Xfce text editor) File->Open.

Steps to reproduce:
- ensure /usr/src/ exists.
- make a clean user profile ($HOME contains only: .bash_history .bash_profile .bashrc)
- start Xfce4
- start klipper
- start avidemux2_gtk or mousepad
- click File->Open
- click "Type a file name" icon to show "Location:"
- type in: /usr/
- wait until autocomplete list is ready
- erase and type in again: /usr/
Result:
location contains text /usr/src//

ArchLinux 686 package versions:
avidemux 2.4.4-1
firefox 3.0.7-1
gtk2 2.14.7-2
glib 1.2.10-7
KDE: 4.2.1 (KDE 4.2.1)
Klipper: v0.9.7
mousepad 0.2.16-1
Qt: 4.5.0
xfce4-clipman-plugin 0.9.0-1
xorg-server 1.5.3-4

Hardware:
Pentium Dual  CPU  E2200  @ 2.20GHz


Further problem:

When using Xfce4 clipman panel plugin with "Add selection to history" enabled
and typing /usr/local/share in some open file dialog i get these entries in the history:
sr/
r/
cal/
al/
l/
are/
re/
e/
When using klipper with option "Ignore selection" disabled (default) i get:
l/
share

This is very weird too, since there was no selection made by the user.

I can (sometimes) reproduce this bug in Ubuntu 8.10 x64 when Parcellite [1] is running.

If I quit Parcellite everything works fine.

[1] http://parcellite.sourceforge.net

The problem is that the file chooser's entry uses the selection in GtkEntry to hold state about "this is what will be inserted if the user hits Tab", but klipper steals the selection ownership.

I'm willing to consider a patch that adds two fields to GtkFileChooserEntry, completion_start_pos and completion_end_pos, and uses *those* to keep the selection bounds instead of GtkEntry's own data.

If klipper is stealing the selection, the user experience will be entirely be broken anyways. No point in trying to work around that.

Hmm, I really think there shouldn't be any selection at all here because the user does not do it. Even if this bug would get fixed, there would still remain the 'further problem' i described in comment #22. It seems to me there should be some separate mechanism to do this competition stuff.

This bug follows me persistently in Archlinux as well. The only way I can get rid of it is by removing xfce4-clipman-plugin.

xfce4-clipman-plugin 1.1.3-1
gtk2 2.18.5-1

Is there a way to make certain widgets impervious to clipboard manager interference?

(In reply to comment #26)
> Hmm, I really think there shouldn't be any selection at all here because the
> user does not do it.

moot point: we programmatically use the selection elsewhere to indicate that a part of the content will be overwritten (e.g. in gnome-screenshot, when saving the screenshot to a file, the file minus the extension will be pre-selected; this is customary to most save dialogs on Gnome).

the problem is the clipboard manager being overzealous and stealing the PRIMARY selection, as well as the CLIPBOARD. actually, the problem is the mere existence of a "clipboard manager" in the XXI century - but let's not digress.

I think the point about abusing selection for state keeping is very valid. There is no way to programmatically find out the common completion or all possible completions. And it's impossible to insert one, even by inserting and selecting text. For what I want, proper state and API would be the right way.
My personal workaround is bookmarks and a mouse pointer. I can't do without persistent clipboard history.

But somehow certain programs can automatically select text without worrying about it getting stolen by a clipboard manager. e.g. the location entry bar in Thunar works exactly the same way as the Filechooser when the clipboard manager is disabled... however when I enable it Thunar keeps working while the Filechooser doesn't.

I've tried to see what Thunar does differently but their code is completely based on the Filechooser code. Hardly anything is different.

Clipman users: A very rudimentary workaround is here: http://aur.archlinux.org/packages/xfce4-clipman-plugin-passive/xfce4-clipman-plugin-passive/nosteal.patch

*** Bug 607485 has been marked as a duplicate of this bug. ***

Apparently Glipper causes the same bug.  Sigh.

While investigating this bug, before finding this bug report, I filmed a short screencast and explanation of the always-buggy behavior while Klipper/Glipper/etc are running.

http://www.youtube.com/watch?v=lkUgA8cwT2U

*** Bug 633604 has been marked as a duplicate of this bug. ***

Xfce users: This is fixed in the git version of xfce4-clipman-plugin. If you use xfce-4.8 you'll also need the git version of xfce4-settings to have things go back to normal. Or you can just kill xfce4-settings-helper.

Stupid Arch changed its policy so the link I posted above no longer works. To see the workaround that makes the xfce clipboard manager play nice with the location bar, just go to https://aur.archlinux.org/packages/xf/xfce4-clipman-plugin-passive/ and download the tarball.

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new