Bug with "Open File" dialog

super8914 · 2017-07-09 13:33:08

I've found a bug in the XFCE "Open File" dialog, but I'm having a hard time giving a precise diagnosis of which is the library/component.

The bug is quite simple. I can always reproduce it; in some conditions it doesn't happen, but I can still make it trigger with certain input. It happens in all the XUbuntu versions, from 16.04 to 17.04. I've found a mention of it in the XFCE mailing lists around 10 years ago (!), but I can't find the post right now.

The procedure is:

- open my text editor (Sublime Text 3)
- invoke the "Open File" action
- in the Location bar, type `~/.`

the autocomplete will kick in but in the erroneous way, and will fill the entry with the first matching entry found (`~/.ecryptfs`), and move the caret to the end.

--------------------

if I want to open, say, ~/.bash_profile, I have to:

- type `~/.`; `~/.ecryptfs` will be filled, and the caret is moved to the end
- while keeping Shift pressed, go back to the position after the dot
- type `ba`, and take a pause (otherwise if I also type `sh`, it will end being `~/.bashsh`) --> `~/.bash` will be filled, and the caret is moved to the end
- type `_p`, and I can finally press Enter

--------------------

A few extra notes on the context under which the problem shows (or not):

- if I perform the same series of steps in Ubuntu Gnome, there is no problem
- with Mousepad, there is no problem

In such conditions, the behavior is different (and correct); if I type something and there are multiple matches, the form is autofilled, and:

- the caret is not moving
- a proposed text is appended, highlighted
- I can keep typing, and match something else

--------------------

One interesting thing is that, in XUbuntu+Sublime Text, sometimes the autocompletion works fine, but I can still trigger it in a very precise way:

- type `~/.`; `~/.ecryptfs` will be filled with the correct behavior (the caret won't move, and the rest of the text is highlighted)
- now type `ba`

the broken behavior will now kick in:

- `sh` will be autofilled, without highlight, and the caret will move at the end
- if I now erase everything and type `~/.`, `~/.ecrypts` will be filled but the caret will move

--------------------

In which library is this bug located?

I thought that it could be a GTK problem, but it doesn't happen in Ubuntu Gnome.

Thanks.

Last edited by super8914 (2017-07-09 13:33:49)

MountainDewManiac · 2017-07-09 22:10:48

According to one of the comments here:
https://forum.sublimetext.com/t/buggy-a … dows/25406

Sublime Text does not auto-complete filenames unless the user has installed one of the plug-ins that serve this function. Are you sure that the fault is not with that particular plug-in? I admit that it does seem unlikely due to the fact that you were unable to reproduce the issue in the GNOME flavor of Ubuntu. But might the two distros be using a different version of that plug-in (or, since there appear to be multiple ones, a different plug-in)?

Regards,
MDM

super8914 · 2017-07-10 07:49:09

I've spent some other time (the first session was gruesome ), and it turns out, this is not an XFCE problem (!).

I've found that the underlying library is GTK (2), and the dialog is the GtkFileChooser - this has been crucial because I was able to find the exact diagnosis, which is described here:

https://bugzilla.gnome.org/show_bug.cgi?id=333320

essentially, it was an accident that I was experincing this on XFCE - it was caused by the fact that when I had installed Gnome/KDE, the clipboard manager [GPaste] was not autostarting. [note that, although the XFCE clipboard manager reports to have fixed the problem, I can still reproduce it]

So, "NOTANISSUE"

Last edited by super8914 (2017-07-10 07:51:56)

Xfce Forum

Sub domains

#1 2017-07-09 13:33:08

Bug with "Open File" dialog

#2 2017-07-09 22:10:48

Re: Bug with "Open File" dialog

#3 2017-07-10 07:49:09

Re: Bug with "Open File" dialog

Board footer