GNOME Bugzilla – Bug 688614
open file dialog causes annoying popup
Last modified: 2018-04-15 00:31:41 UTC
Created attachment 229329 [details] screenshot of the annoying popup. some privacy info erased Dear gedit devs, (Screenshot attached is also here: http://i.imgur.com/wlEA9.png) 1) Code in gedit... 2) Click open... 3) Click on a parent folder, or other... 4) Annoying "popup" type overlay "window?" appears, right over the files! 5) Clicking on it selects that path, instead of changing to it in one click the way clicking in the normal file browser does. This is causing RSI with the addtional clicks ;) This is driving me and my friends crazy! Fixes and especially temporary workarounds would be much appreciated. Many thanks, James PS: Marking as major since this is driving people mad ;)
Is this happening only in gedit or in all gtk+ apps? Seems like a gtk+ "feature" to me.
Fortunately, I've only noticed this in gedit. While I agree that it is a GTK+ issue, I figured that: 1) Maybe gedit is setting some flag that enables this 2) Maybe gedit devs notice this and are in a better place to diagnose and track down what it is. 3) Got to start somewhere! Are you able to reproduce this or ping the right GTK+ person? Thanks again, Let me know if you need more info. James
I can easily reproduce this in for example rhythmbox. I don't think we set any special flag to enable this behavior. I agree that it seems like a pretty useless behavior (although you can just press Escape to hide the popup again). The popup seems to basicly scale particularly badly when you have many results (it could just limit the height and scroll more). Anyway, reassigning to gtk+
Thanks for looking into this Jesse!
I have this too in many gtk+ apps and it is very annoying and standing in the way each time I use this dialog to select some folder. Would be very grateful if someone would look into it! :)
Forgot to mention: Using gtk3-3.6.2 on Arch Linux
I found a workaround! Open dconf-editor, navigate to org/gtk/settings/file-chooser and change location-mode => filename-entry to location-mode => path-bar This way file dialog won't display filename entry field when *selecting folders* and this popup which is really annoying (want to stress that again :)) won't be shown! Hurray! But this obviously is a bug of filename-entry mode of gtk+ file chooser, would really appreciate devs fixing it, thanks! :)
(In reply to comment #7) > I found a workaround! > > Open dconf-editor, navigate to org/gtk/settings/file-chooser and change > > location-mode => filename-entry > to > location-mode => path-bar > > This way file dialog won't display filename entry field when *selecting > folders* and this popup which is really annoying (want to stress that again :)) > won't be shown! > > Hurray! > > But this obviously is a bug of filename-entry mode of gtk+ file chooser, would > really appreciate devs fixing it, thanks! :) Oh brilliant. I can confirm that this is now not bothering me. Hopefully this setting sticks between reboots and whatnot. Thanks Dmitry.
Federico, why would we ever pop up the completions for an empty entry ? While I can't reproduce the spontaneous popup with 3.6/3.7, I do get a completion popup with an empty entry if I first enter some character, and then remove it with backspace. That shouldn't happen...
I'm not sure why you can't reproduce it right away, but this might have to do with something like recent folder/file which was recorded somewhere. Because this varies from program to program. For example in gnome's file-roller I *always* get '.' in that entry and popup always shows completions like .local, .config, etc - whole lot of . dirs. In the nautilus' 'Copy To...' this entry contains some subdir of current or previous dir and messes up an open button. I.e. this varies from app to app, (but what's constant is popup :)) so I suspect this also has something to do with a per-app setting which gets used by file-chooser dialog.
*** Bug 687514 has been marked as a duplicate of this bug. ***
*** Bug 706934 has been marked as a duplicate of this bug. ***
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