GNOME Bugzilla – Bug 771127
Radio button bullet not always rendered correctly after selection (transition does not complete?)
Last modified: 2018-02-13 15:45:13 UTC
Fedora QA uses the openQA screenshot-based automated testing system. Lately some of its tests of Fedora Rawhide seem to be failing due to a problem with how GTK+ renders radio button bullets. In its install tests, it goes into the installer SOFTWARE SELECTION page and changes the software selection (usually). It then checks it selected the right thing by comparing a small area of the screen including part of the package set name and the radio button in its 'selected' state. Usually this works fine, but recently we occasionally see it fail because the radio button looks a bit different than it expects. Here's some examples: https://openqa.fedoraproject.org/tests/32069#step/_software_selection/11 (smaller) https://openqa.fedoraproject.org/tests/30854#step/_software_selection/11 (smaller) https://openqa.stg.fedoraproject.org/tests/41001#step/_software_selection/7 (greyer) You can compare the 'needle' - the reference screenshot - and what the test looked like by dragging the orange line to and fro across the match area. On the left is the reference needle, on the right is how the same area of screen looked in the test. You can also go to the 'Logs & Assets' tab to get a (sped-up) video of the install attempt. Note that openQA doesn't just take one screenshot then pass or fail, it keeps 'looking' for about 30 seconds. As you can also see from the video, the button is clearly stuck in the state it's in (it's not just that openQA caught it in the middle of a transition or something). I think possibly what's happening is that a transition is not completing, and the button gets stuck in the interim state?
Looks like this affects at least 3.21.4 and 3.21.5; I can see examples of the same thing with current Rawhide (3.21.5) and recent F25 (3.21.4). I don't recall precisely when it started, but I can probably look back and work it out.
Best I can tell, GTK_DEBUG=no-css-cache does not help this. I made an anaconda updates image: https://www.happyassassin.net/updates/bgo771127.img which should run `GTK_DEBUG=no-css-cache anaconda` - it modifies /usr/share/anaconda/tmux.conf , which is where the anaconda launch command actually lives - and also adds a log statement to /usr/sbin/anaconda: log.info("GTK_DEBUG: " + os.environ.get('GTK_DEBUG', "not set")) booting manually with that image the log message indicates the env setting worked: INFO anaconda: GTK_DEBUG: no-css-cache but the bug still seems to happen. I wrote a special test for openQA which just goes to the software selection screen and loops through flipping the selection between 'Fedora Server' and 'Fedora Custom Operating System' 100 times, checking the needle match for the 'custom' selection every time. When I run that test 8 times in parallel, at least some of the runs always hit the bug, and with that updates image, they still do.
Does the problem go away if you disable animation ? gsettings set org.gnome.desktop.interface enable-animations false
Disabling animation does seem to help, yes. I taught openQA to do it via the GTK+ inspector, and with that workaround, the bug does not seem to happen.
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.
I don't *think* this is still happening; one of the relevant needles did match recently, but from the video I *think* it just happened to match during the transition, it wasn't needed because the transition did not complete. Will close for now.