After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 734033 - Avoid initial keyboard focus heuristic selecting labels
Avoid initial keyboard focus heuristic selecting labels
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-07-31 10:08 UTC by Kalev Lember
Modified: 2018-04-15 00:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Factor out GtkDialog's initial keyboard focus heuristic to GtkWindow (5.47 KB, patch)
2014-07-31 10:13 UTC, Kalev Lember
none Details | Review
my approach (7.26 KB, patch)
2014-08-01 23:20 UTC, Matthias Clasen
none Details | Review
dialog part (759 bytes, patch)
2014-08-01 23:21 UTC, Matthias Clasen
none Details | Review
test (681 bytes, patch)
2014-08-01 23:21 UTC, Matthias Clasen
none Details | Review

Description Kalev Lember 2014-07-31 10:08:54 UTC
GtkDialog currently has a heuristic that skips labels when figuring out where to put initial keyboard focus, but in some cases it can conflict with the initial keyboard focus code in GtkWindow that simply picks the first tabbable widget.

E.g. I get this in gnome-software: https://kalev.fedorapeople.org/gnome-software-selected-label.png

I couldn't come up with any use case that would actually want to have labels come up selected, so I went ahead and improved the heuristics to skip labels in all cases.

I have a patch that fixes this for me and improves the heuristics for both GtkDialog and GtkWindow.  mclasen mentioned of plans to add an explicit way for setting an initial keyboard focus in ui files, but if that doesn't happen in time for 3.14 it would be nice to have something along those lines as the patch here to go in to fix the gnome-software dialogs.
Comment 1 Kalev Lember 2014-07-31 10:13:32 UTC
Created attachment 282131 [details] [review]
Factor out GtkDialog's initial keyboard focus heuristic to GtkWindow

Previously, GtkDialog and GtkWindow had two separate code paths for
finding the initial keyboard focus. GtkDialog would pick the first
non-label widget, but GtkWindow would simply pick any widget that
accepted keyboard focus. This commit moves the GtkDialog non-label
finding code to the base class, ensuring they both behave similarly.

In particular, this improves the heuristic for GtkDialogs with a few
labels and 0 action buttons and avoids having those getting mapped with
a label selected.
Comment 2 Matthias Clasen 2014-08-01 23:20:51 UTC
Created attachment 282300 [details] [review]
my approach
Comment 3 Matthias Clasen 2014-08-01 23:21:24 UTC
Created attachment 282302 [details] [review]
dialog part
Comment 4 Matthias Clasen 2014-08-01 23:21:50 UTC
Created attachment 282303 [details] [review]
test
Comment 5 Matthias Clasen 2014-08-02 10:01:09 UTC
I've pushed slightly different patches that avoid adding new UI.
Comment 6 Kalev Lember 2014-08-02 11:47:19 UTC
Thanks, this looks like a very useful thing to have.

However, in my case with https://kalev.fedorapeople.org/gnome-software-selected-label.png , there is no good widget to set the initial focus on. What I'd like to have there is a way to unset the initial focus (set it to NULL), instead of choosing a particular widget -- this dialog only has labels to choose from for initial focus.
Comment 7 Matthias Clasen 2014-08-02 20:14:43 UTC
hmm, ok. have to try harder.

For now, this works as a workaround:

static void
unset_focus (GtkWidget *widget)
{
  GtkWidget *focus;

  focus = gtk_window_get_focus (GTK_WINDOW (widget));
  if (GTK_IS_LABEL (focus))
    gtk_label_select_region (GTK_LABEL (focus), 0, 0);
  gtk_window_set_focus (GTK_WINDOW (widget), NULL);
}


  g_signal_connect_after (dialog, "show", G_CALLBACK (unset_focus), NULL);
Comment 8 Matthias Clasen 2018-02-10 05:07:46 UTC
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.
Comment 9 Matthias Clasen 2018-04-15 00:30:18 UTC
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