gtkfilechooser save/save as dialog misplaces focus

Bug #130224 reported by Michael Knepher
112
This bug affects 8 people
Affects Status Importance Assigned to Milestone
GTK+
Fix Released
Medium
One Hundred Papercuts
Invalid
Undecided
Unassigned
gtk+2.0 (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: libgtk2.0-0

With libgtk2.0-0 v. 2.11.6-1ubuntu3

1. From any app that can save/save as files, choose File->Save or File->Save As...
2. Focus is on the file list window of the dialog, so typing anything activates the "find-as-you-type" feature

rather than

Expected behavior: focus should be on the filename text input

Related branches

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Confirmed, this is totally reproducible in gutsy, thanks for your report.

Changed in gtk+2.0:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Sebastien Bacher (seb128) wrote :
Changed in gtk:
status: Unknown → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

The bug is fixed upstream now

Changed in gtk+2.0:
status: Triaged → Fix Committed
Changed in gtk:
status: New → Fix Released
Revision history for this message
Sebastien Bacher (seb128) wrote :
Download full text (5.5 KiB)

 gtk+2.0 (2.12.0-0ubuntu1) gutsy; urgency=low
 .
   * New upstream version:
     GtkTooltips
     - All widgets have been ported to the new tooltips code
     - Tooltips are disabled in touchscreen mode
     GtkBuilder
     - Support custom tabs in GtkPrintUnixDialog
     Bugs fixed:
     - 459561 critical warnings with custom tooltips
     - 461648 GdkWindowQueueItem::serial overflow
     - 463773 Openoffice and flash run into a deadlock when used with KDE
     - 468801 thunar segfaults when selecting targa image (LP: #127574)
     - 473441 [patch] Ungrab windows when gdk_window_destroy() is calle...
     - 473954 gnome-background-properties: crash on drag-n-drop to "Add...
       (LP: #128931)
     - 461945 totem outputs errors in terminal (LP: #129438, #130329)
     - 348493 _gdk_quartz_copy_to_image needs implementing for pixmaps
     - 405868 Missing implementation of gdk_window_get_geometry()
     - 441219 Do not allow moving cursor to separators
     - 447214 rename the tips_data_list field back
     - 451202 New tooltips API has too long default timeout (LP: #133919)
     - 451397 Use new tooltip API in gtk+
     - 452225 check and option mark drawing is a mess of inconsistency
     - 457642 tooltips on notebook's tab labels
     - 458088 Improve mouse cursor for paned widgets
     - 458102 GtkScrolledWindow doesn't redraw when gtk-scrolled-window...
     - 458280 remove set-toolip handler from menutoolbutton
     - 458298 broken cursor movement with inline selection
     - 459459 Missing implementation of gdk_window_set_decorations() an...
     - 459515 gtk_menu_key_press() buglets
     - 459566 update testtooltips
     - 459667 Missing implementation of gdk_window_set_keep_above and g...
     - 460272 GtkFrame publishes incorrect defaults for "label-xalign"
     - 460534 No expose events if input swamps main loop with scrolled ...
     - 461225 gtk_tree_view_set_tooltip_cell() documentation: cell
      -463907 'Recent Documents' is broken in gnome-panel 2.19.5 (LP: #131266)
      -464528 gdk_rectangle_union() and gdk_rectangle_intersect() shoul...
     - 465039 "keynav-failed" signal not emitted when treeview has just...
     - 467003 tooltips do not pick up theme changes
     - 467117 Documentation for the GtkPaned key binding signals
     - 467414 gtkcupsutil.c won't build with cups 1.3
     - 468055 Incorrect compose mapping for capital U with macron (LP: #113721)
     - 468245 Tooltip timer doesn't get reset when mouse leaves into ot...
       (LP: #135076)
     - 469214 Recently used blocks side-panel browsing until loaded
     - 469374 menu accelerators don't work
     - 469395 make dist failure
     - 471132 Highlighting a suggestion with the keyboard changes the U...
       (LP: #134304)
     - 471215 Cursor drawing broken
     - 472974 gtk-builder-convert doesn't set correctly the tab label f...
     - 472981 make gtk-builder-convert not remove some empty properties
     - 356630 Print to file dialog suggests "output.pdf" even for ps ou...
     - 447883 PATCH Documentation about SVN in HACKING and README.cvs-c...
     - 459340 GtkContainer API documentation refers depre...

Read more...

Changed in gtk+2.0:
status: Fix Committed → Fix Released
Revision history for this message
Matthew Nuzum (newz) wrote :

Is the fix released? As of today, Friday, Sept 21st, this problem is still evident on a fully updated Gutsy. (I saw numerous gtk2 updates come through and I've restarted the computer)

Revision history for this message
Sebastien Bacher (seb128) wrote :

that's still happening, reopening

Changed in gtk+2.0:
status: Fix Released → Triaged
Revision history for this message
xtknight (xt-knight) wrote :

I still have the problem on Gutsy. What's the status?

Revision history for this message
Sebastien Bacher (seb128) wrote :

xtknight, if the bug is still open and had recent comments there is no need to add comments to say it's still there. About the status you can read the bug comment, there is thousand of bugs and only limited ressources to work on them, the code is opensource though so patches are welcome

Changed in gtk:
status: Fix Released → New
Revision history for this message
xtknight (xt-knight) wrote :

Sebastien: Understood. I was mainly wondering what "Triaged" meant in the grand scheme of things. Thank you for dealing with this bug.

Revision history for this message
Brett Alton (brett-alton-deactivatedaccount) wrote :

Confirmed in 2.12.0-1ubuntu3.

I submitted a duplicate bug just yesterday.

Maybe a Ubuntu-specific patch is in order?

I wish I knew C so I could help out :P

Revision history for this message
Brett Alton (brett-alton-deactivatedaccount) wrote :

Oh and here is the screen I submitted in my duplicate bug: http://launchpadlibrarian.net/10851010/saving_in_gedit.png.

Just in case someone needs a visual!

Revision history for this message
Alexander Jones (alex-weej) wrote :

Just to clarify, this is a problem when the "Browse for other folders" expander is open. If it's closed when you open the dialogue, there's no bug.

Revision history for this message
Baptiste Mille-Mathias (bmillemathias) wrote :

The problem is still present for me with libgtk 2.12.7-1 in hardy.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gtk+2.0 - 2.12.7-1ubuntu1

---------------
gtk+2.0 (2.12.7-1ubuntu1) hardy; urgency=low

  * debian/patches/080_from_upstream_fix_fileselector_focus_issues.patch:
    - change from upstream to fix fileselector focus issues
      (LP: #93396, #130224)

 -- Sebastien Bacher <email address hidden> Wed, 06 Feb 2008 10:51:25 +0100

Changed in gtk+2.0:
status: Triaged → Fix Released
Changed in gtk:
status: New → Fix Released
Revision history for this message
Rkimber (rkimber) wrote :

The situation as I see it now is that if (say, in Bluefish) I want to save a file as 'filename.htm' I choose 'save as' and the original 'filename' is highlighted so that I can type over it if I want (though I'm not sure why it assumes I always want to keep the same htm 'extension'). That much works fine.

But if I click on another file and type anything, the name field goes blank and further typing opens a small text field further down the window. It's not clear what (if anything) this does. Similarly, the name field goes blank if I click on another directory.

Surely all we need is that the original filename is highlighted and active, and remains highlighted and active until we type over it, or press 'save'.

I'm using ubuntu 8.04, with libgtk2 (2.19.9-3Ubuntu3)

Revision history for this message
Alexander Jones (alex-weej) wrote : Re: [Bug 130224] Re: gtkfilechooser save/save as dialog misplaces focus
  • unnamed Edit (301 bytes, text/html; charset=ISO-8859-1)

The small text field is the GtkTreeView filter. It is needed for keyboard
browsing.

The problem here is actually that, as soon as the directory browser is
revealed, it takes focus, unconditionally. What I think should happen is
that using the expander should transfer focus to the browser.

Revision history for this message
Ceriak (ceriak) wrote :

It is still an issue in Intrepid…

Revision history for this message
komputes (komputes) wrote :

Tested. Not an issue in Intrepid or Jaunty.

Revision history for this message
Scott Enderle (scott-enderle) wrote :

I'm afraid I have to agree with Ceriak. This is still an issue in Intrepid, at least for me.

As Rkimber stated, it's no longer a problem if you open the dialog and type a filename directly. The problem happens when you navigate to another folder using the GtkTreeView. The text in the filename box remains highlighted, but when you attempt to type over it, you wind up entering text into the GtkTreeView filter. At the very least, the filename box text should be grayed out or deselected, to convey that it needs to be refocused in order to be edited.

Frankly, I don't see the TreeView filter as a useful tool in this context; more useful would be an integrated filename box/filter. I don't know if such a thing is practically possible. But leaving the filename highlighted is plain bad ui design -- it's confusing and disorienting -- and it ought to be changed.

Revision history for this message
Aethralis (aethralis) wrote :

Can confirm that this is an issue also in Jaunty as described by Rkimber and Scott Enderle.

Revision history for this message
Ralf Hersel (ralf.hersel) wrote :

I confirm for Jaunty as well.
This is not bad ui design - it is a bug.
It is a bug when the filename is highlighted but the treeview has the focus.
Everybody would expect that the highlighted filename will be overwritten but nobody would expect to filter the treeview. So please fix it.

Changed in hundredpapercuts:
status: New → Confirmed
Revision history for this message
David Siegel (djsiegel-deactivatedaccount) wrote :

Can someone list steps to reproduce this behavior in Jaunty? It appears fixed to me.

Revision history for this message
Brett Alton (brett-alton-deactivatedaccount) wrote :

The problem appears fixed to me as well. Whenever I use gedit or firefox to save a file, I can start typing immediately as the text field has focus by default.

Revision history for this message
Ralf Hersel (ralf.hersel) wrote :

Hi David
No, it is definitely not fixed.
Here are the steps to reproduce it in Ubuntu 9.04:

1. open GEDIT
2. click SAVE
3. click on a folder
4. notice that the filename is still highlighted but your typing will go
to the treeview filter instead to the filename (wrong focus)

Regards
Ralf

Revision history for this message
Brett Alton (brett-alton-deactivatedaccount) wrote :

That's because you just clicked on a folder, so now the focus is with the folders, not with the filename. The problem was previously that the filename text field was never in focus when the dialog first opened. Now it is in focus when it's first opened, but if you move the focus to a folder (like you said) how is it supposed to know that you want to know type the filename?

Revision history for this message
David Siegel (djsiegel-deactivatedaccount) wrote :

Ralf, there is a different bug filed for that issue.

Changed in hundredpapercuts:
status: Confirmed → Invalid
Revision history for this message
Ralf Hersel (ralf.hersel) wrote :

Ok, David. Can you please give me the link to that other issue. Thanks

Revision history for this message
Ralf Hersel (ralf.hersel) wrote :

Hello Brett
The problem is, that the filename remains highlighted even when you click a folder. Therefore the user supposes that he can start overwriting the filename (because it is highlighted), which is not the case. The expected behaviour would be, that the filename gets the focus as soon as you changed the folder.

Revision history for this message
Ralf Hersel (ralf.hersel) wrote :

David, I found it myself. It is https://bugs.launchpad.net/bugs/387934

Revision history for this message
RedRat (jwekell) wrote :

How about removing the highlight of the pseudo file name then. If the
focus is on the folder, highlight the folder but do not highlight the
suggested filename.

Brett Alton wrote:
> That's because you just clicked on a folder, so now the focus is with
> the folders, not with the filename. The problem was previously that the
> filename text field was never in focus when the dialog first opened. Now
> it is in focus when it's first opened, but if you move the focus to a
> folder (like you said) how is it supposed to know that you want to know
> type the filename?
>
>

Revision history for this message
Michael Knepher (mknepher) wrote :

Currently, the highlighted color changes depending on whether the filename string has focus or not. Being able to tell whether the text is in focus or not probably depends a great deal on the gtk theme. This is probably something for some usability folks to look at and further discussion should take place on https://bugs.launchpad.net/bugs/387934. The original behavior I reported in this bug does appear to be fixed.

Revision history for this message
Scott Ritchie (scottritchie) wrote :

I don't think we're quite done here - we still need to figure out if some areas of the dialog should have focus even after the user clicks on them. There are two cases where we would want this:

1) if the user doesn't need to search, typing should go towards the user's other task (changing the to be saved filename)
2) if the user doesn't know that searching is even possible, then they will navigate manually before searching

The places section, in particular, is something that doesn't need to be searched since it is so small - removing focus from the filename save as gets in the way in that case. I'm not sure about 2, but it will require user testing.

Revision history for this message
Scott Ritchie (scottritchie) wrote :

This is still live (and very annoying) in Firefox for Karmic by the way. Right click an image to save, go to the folder you want to save it to, and start typing to rename it - your text will have no effect.

Changed in gtk+2.0 (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

don't reopen closed bugs but open a new one

Changed in gtk+2.0 (Ubuntu):
status: Confirmed → Fix Released
Changed in gtk:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.