GNOME Bugzilla – Bug 776322
Gtk::Expander clicking on collapsed widgets
Last modified: 2017-08-29 08:54:43 UTC
Created attachment 342279 [details] minimal example case Sometimes clicks are going through a collapsed Gtk::Expannder to the hidden widgets inside. I've attached a minimal example where the behavior can be consistently reproduced. build with: g++ -o expand_test expand_test.cpp `pkg-config --cflags --libs gtkmm-3.0` The example has 2 buttons, each inside an expander, inside a grid. Expander 1 starts collapsed; expander 2 expanded. Each button has a button_pressed event that prints a message to stdout 0. all widgets work normally at start 1. expand expander 1, then close it again. 2. try to close expander 2. It won't close, and the button_pressed event is triggered for button 1 3. try to press button 2 near the top of the button. The button_pressed event is triggered for button 1 again. 4. press button 2 near the bottom of the button. the button_pressed event for button 2 is triggered as expected. 5. If you expand expander 1 again, all widgets work normally. It seems like the widgets in expanders are not being properly 'hidden' and are still receiving clicks when clicking in their old position. The bug behavior may be influenced by widget positioning so it may not be reproducible on some themes (I'm using Adwaita). System info: $ pkg-config --modversion gtkmm-3.0 3.22.0 $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.1-5' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 6.2.1 20161124 (Debian 6.2.1-5) $ uname -srvmo Linux 4.8.0-1-amd64 #1 SMP Debian 4.8.7-1 (2016-11-13) x86_64 GNU/Linux
I've also gotten the same behavior on windows (windows 7 64-bit) $ pkg-config --modversion gtkmm-3.0 3.22.0 $ g++ -v Using built-in specs. COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-6.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 6.2.0 (Rev2, Built by MSYS2 project)
This looks similar to gtk+ bug 774134.
*** This bug has been marked as a duplicate of bug 776937 ***
Thanks for the useful info and test case (well, normally a C version is best, but I'm biased because I like gtkmm :P). This should be resolved by the fix from the duplicate on the GTK+ side.
The commit in bug 776937 in an improvement, but the test case still does not work quite right in the gtk-3-22 branch. The master branch is OK. Start the test case (gtk-3-22). The first thing you do, click on the expanded Button 2. Expander 2 is collapsed, as if the expander and not the expanded button had been clicked. After that, everything works correctly. > well, normally a C version is best It's quite natural that the reporter has supplied a C++ test case, as this is a gtkmm bug.
(In reply to Kjell Ahlstedt from comment #5) > The commit in bug 776937 in an improvement, but the test case still does not > work quite right in the gtk-3-22 branch. The master branch is OK. > > Start the test case (gtk-3-22). The first thing you do, click on the expanded > Button 2. Expander 2 is collapsed, as if the expander and not the expanded > button had been clicked. After that, everything works correctly. There is https://bugzilla.gnome.org/show_bug.cgi?id=774134 for that; maybe it proves to have a similar cause, but let's see. I don't recall being able to replicate any of the problems with collapsing, though maybe I just missed something in my tests.
To replicate the problem, you must click Button 2 before you click any of the expanders.
(In reply to Kjell Ahlstedt from comment #7) > To replicate the problem, you must click Button 2 before you click any of the > expanders. Oh, yeah. Thanks. 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! Let's figure this out over at Bug 774134.