GNOME Bugzilla – Bug 774134
GtkExpander: input window of title extends over child, if :expanded is true before shown
Last modified: 2017-08-29 20:25:10 UTC
Dear maintainers, when manually expanding a GtkExpander with `gtk_expander_set_expanded()`, the GtkExpander acts funny. I see two misbehaviors: - the children don't have focus - any click on the children will close the GtkExpander So, I have a GtkExpander in my UI, and I wish that it's expanded by default. At the moment it's not possible due to this bug. You can find a complete example to reproduce this bug here: https://gist.github.com/elboulangero/1927f1af1b7b463fe6740ee69341a5a3 Is there something I'm doing wrong ? Best regards, Arnaud
I don't see the problems you describing. Clicking on the children works fine here, without closing anything. Setting the focus needs to happen separately.
what version of gtk is this with ?
This is gtk shipped with debian. I'll try again with upstream gtk in a couple of days then.
Hi, First, I made a short video to show you what happens: https://youtu.be/2vymAwH-xUE About focus: I guess I used the wrong words. What I mean is that, when I hover on the link in this example, there's no reaction. The mouse cursor doesn't change to a hand, as expected with a link, and the link itself doesn't react either. Then, clicking on the link causes the expander to close. Then, after re-opening the expander, everything works as expected. All of that you can see on the video. Second, I compiled Gtk+ from git, and it still behaves the same. BTW, the display backend is X11, in case it's of any interest.
When I try the test case in comment 0, GtkExpander does not behave as expected. Nor does it behave as elboulangero describes. - If the expander starts with a hidden child, it behaves as expected as long as the child is hidden. - When the child is expanded, the expander also behaves as expected. - When it has been expanded and is then compressed, it's not ok. The child widget disappears from view as it should, but if the cursor is located where the child was once displayed, it behaves as if the child widget were still there. The cursor changes to a hand. If the mouse is clicked, the link opens in Firefox although the link is not shown. I've tested with gtk+-3.0 3.20.9 in Ubuntu 16.10, and with gtk+-4.0 from the master branch in the git repository, pulled a few days ago. The behaviour is the same in both cases. This is similar to what's reported in gtkmm bug 776322. The test case in bug 776322 is a small gtkmm program. I can translate it to gtk+ if that would be helpful.
(In reply to Kjell Ahlstedt from comment #5) > I've tested with gtk+-3.0 3.20.9 in Ubuntu 16.10, and with gtk+-4.0 from the > master branch in the git repository, pulled a few days ago. The behaviour is > the > same in both cases. Could you retest with current master? It has removed all GtkCssGadgets and replaced them with widgets, and the Expander child is kept in a box gadget as of 3.22, so a possible difference here could help narrow down the cause.
By master, do you mean Gtk+4 from git ? I just run a couple of test on my laptop and found something interesting. I have two systems installed there, both are up-to-date Debian Stretch. One system has Openbox+Compton running for window management, and this system still exhibits the bug. Package versions are: libgtk-3-0:amd64 3.22.11-1 libx11-6:amd64 2:1.6.4-3 openbox 3.6.1-4 compton 0.1~beta2+20150922-1 The other system is GNOME. On this system, no bug, the GtkExpander works just fine. Packages are: libgtk-3-0:amd64 3.22.11-1 libx11-6:amd64 2:1.6.4-3 gnome-core 1:3.22+3 mutter 3.22.3-2 It doesn't make sense to me, but hopefully it does for someone :)
(In reply to elboulangero from comment #7) > By master, do you mean Gtk+4 from git ? I did indeed - but still, these additional tests on 3.22 are also appreciated and hopefully might suggest a possible direction. Thanks!
I've tested with gtk+ and gtkmm from git's current master branch. Both the C++ program in bug 776322 and the C program in this bug work correctly. No reaction if the cursor is hovering over or the mouse is clicked at a place where there is no visible widget. The only doubtful behaviour (or lack of behaviour) is that the cursor does not change to a hand when it's hovering over the link in this bug's test case. But the link opens in a web browser when the mouse is clicked, and tooltips are shown as expected in the C++ test case. Tested in Ubuntu 17.04, both with desktop environment GNOME Flashback (Compiz) and UBUNTU (Default).
Hey, I managed to build GTK+ from git, and I tested again on my Openbox+Compton system. This time it worked as expected. So I'm personally OK to close this bug.
Thanks both for the tests. (In reply to Arnaud Rebillout from comment #10) > Hey, I managed to build GTK+ from git, and I tested again Do you mean you build GTK+ 4, i.e. the master branch? While it's good if this has been resolved in GTK+ 4 somehow, we should keep it open while the issue might still exist in 3.22
*** Bug 776937 has been marked as a duplicate of this bug. ***
The test case works OK for me on GTK+ 3.22.16 on Windows. I'd still like to hear whether you both see the problem on GTK+ 3. Thanks in advance!
> Do you mean you build GTK+ 4, i.e. the master branch? Yep that's what I mean, GTK+ 4 master branch. I can't reproduce the bug with this version. I just had a look at the branch `gtk-3-22`, and the last commit on the file `gtk/gtkexpander.c` is one year old, so I guess there no need to compile and test anything there. Or should I ? As I said on the message above, the bug is still present on Debian libgtk-3-0 3.22.11-1, when using Openbox & Compton for the window management.
*** Bug 779682 has been marked as a duplicate of this bug. ***
(In reply to Arnaud Rebillout from comment #14) > I just had a look at the branch `gtk-3-22`, and the last commit on the file > `gtk/gtkexpander.c` is one year old, so I guess there no need to compile and > test anything there. Or should I ? I'd appreciate if you could test with a new build including https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=32553ad3a2068be6d099d9a045c0403b799c2700 from https://bugzilla.gnome.org/show_bug.cgi?id=776937 That fixes what Kjell described in Comment 5, so we can ascertain whether your report is somehow related, or a separate issue. I suspect the latter, but maybe that other bug had other strange effects that I didn't see while investigating.
*** Bug 783145 has been marked as a duplicate of this bug. ***
Concerning bug 783145 I tested it with branch gtk-3-22 (version 3.22.19). But no difference. However I noticed that collapsing of the expander does not happen each time. Sometimes it's working correctly. It just happens so rarely that I didn't noticed it before. And it was the same with 3.22.17. (I failed to compile the master branch. Too many new dependencies ...)
@Andreas I also struggled a bit to build the master branch. I ended up creating a docker container for that, it's available at https://github.com/elboulangero/docker-gtk. You can give it a try if you want. There might be better ways to build GTK+, but I'm not aware of it, so that's my solution for now. @Daniel OK I just build the latest `gtk-3-22` branch, which includes your commit, but it doesn't change anything, the bug is still there. Sorry ;)
(In reply to Arnaud Rebillout from comment #19) > There might be better ways to build GTK+, but I'm not aware of it I use jhbuild, which works great. > @Daniel OK I just build the latest `gtk-3-22` branch, which includes your > commit, but it doesn't change anything, the bug is still there. Sorry ;) Thanks for trying. I don't know why this fails under OpenBox/Compton; maybe someone else has an idea, otherwise further investigation is needed.
See also the test case in Bug 776322 - which, for me, fails as follows: (In reply to Kjell Ahlstedt from comment #7) > To replicate the problem, you must click Button 2 before you click any of the > expanders. Click #1: It causes its parent Expander to collapse. Click #2 in the area where the button was: It acts like it was still there and you pressed it!
That was with GTK+ minus the committed patch from Bug 776322; I'll check on an up-to-date build later, but Kjell said it still happens there too.
So the issue is not exactly that clicking on the child collapses the expander; rather, GTK+ thinks that the cursor is over the title node. You can see this just by hovering over the button: the arrow of the title node gets the prelight state. When first shown with :expanded == TRUE, the title's input window covers the entire Expander.
Calling queue_resize() on the 2nd expander fixes this - but _only_ if that's called after the window is show()ed.
and my guess is that is because gtk_expander_realize() just sets the whole-widget allocation on priv->event_window
Created attachment 358678 [details] [review] Expander: Don’t set input_window over whole widget realize() gave the input_window the allocation of the whole widget. This was wrong; it should be that of the title_gadget, as in size_allocate(). This broke expanders in which :expanded is TRUE before showing: Input over the entire widget was sent to the title, making the child unable to receive it. Clicking the child unexpectedly collapsed it. Once expanded again, things fixed themselves as size_allocate() fixed the input_window alloc. So, queuing a reallocate or resize after show() was a workaround. Fix by assigning the allocation of the title_gadget, to match what size_allocate() does. That is symmetrical and just plain correct. -- This is untested but seems blatantly correct, so I'll probably just push after testing later, but if anyone can test before that, I'd still appreciate it.
Created attachment 358679 [details] [review] Expander: Don’t set event_window over whole widget no idea where I got "input_window" from
I just tested your patch, it works great and fixes the issue for me. Congrats ! Beer time !
The patch in comment 27 (plus the already pushed patch from bug 776937) fixes the problem in gtkmm bug 776322.
Attachment 358679 [details] fixes the problem for me concerning bug 783145. Thank you for your effort.
Thanks a lot, everyone! Expander may now actually be ready for primetime. :P Attachment 358679 [details] pushed as 18a6c5c - Expander: Don’t set event_window over whole widget
btw, I should've noted that, while I couldn't replicate this bug on GNOME/X11/mutter, I did replicate and confirm it fixed on Windows. I have no idea but guess that maybe the GNOME stack coincidentally caused a reallocate in time, suppressing the problem.