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 752247 - Button still shows as insensitive when it's actually sensitive (anaconda hub)
Button still shows as insensitive when it's actually sensitive (anaconda hub)
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
3.17.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
: 752200 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-07-10 19:37 UTC by Adam Williamson
Modified: 2015-07-14 02:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
hub from Rawhide nightly with GTK+ 3.17 (note apparently-inactive 'Begin Installation' button and light backgrounds on several spokes) (142.74 KB, image/png)
2015-07-10 19:37 UTC, Adam Williamson
Details
hub from F22 final with GTK+ 3.16 (note active 'Begin Installation' button and no light backgrounds on spokes) (135.34 KB, image/png)
2015-07-10 19:38 UTC, Adam Williamson
Details

Description Adam Williamson 2015-07-10 19:37:08 UTC
In the Fedora installer, after you boot to the installer and complete the 'Installation Destination' screen and return to the 'hub' (main overview screen), the 'Begin Installation' button ought to be active - it should be blue colored with white text. This is how it behaves in Fedora 22, with GTK+ 3.16.

However, with current Fedora Rawhide nightly images - e.g. https://kojipkgs.fedoraproject.org/mash/rawhide-20150710/rawhide/x86_64/os/images/boot.iso - after completing the 'Installation Destination' screen, the 'Begin Installation' button still displays as if it were inactive - grey text on a flat, light grey button. It actually *is* active, though - you can click it and the installation process starts. The fact that it doesn't display correctly is breaking our automated tests (openQA).

Also you can see in the screenshot that several spokes still have light backgrounds. Usually they have light backgrounds while they are in some kind of 'processing' state, then when they're complete, they get the slightly darker background (same color as the canvas). This could well be another symptom of the same bug, as it's again an element not updating properly from a sort of 'in process' state to a 'ready' state?

Attaching two screenshots, one showing F22 final after completing the 'Installation Destination' spoke (that's with GTK+ 3.16), one showing the 2015-07-10 Rawhide nightly image (that's with GTK+ 3.17 - the same image linked above) after completing the 'Installation Destination' spoke.
Comment 1 Adam Williamson 2015-07-10 19:37:52 UTC
Created attachment 307267 [details]
hub from Rawhide nightly with GTK+ 3.17 (note apparently-inactive 'Begin Installation' button and light backgrounds on several spokes)
Comment 2 Adam Williamson 2015-07-10 19:38:41 UTC
Created attachment 307268 [details]
hub from F22 final with GTK+ 3.16 (note active 'Begin Installation' button and no light backgrounds on spokes)
Comment 3 Matthias Clasen 2015-07-13 11:46:11 UTC
3.17.what?
Comment 4 Adam Williamson 2015-07-13 15:16:04 UTC
Well, 3.17.4-1 . That was the last build for Rawhide, a couple of weeks ago.
Comment 5 Benjamin Otte (Company) 2015-07-13 15:26:15 UTC
I have the suspicion that GTK's tick fuctions do not get run in anaconda - which is how GTK triggers animations (buttons are animated to do smooth transitions). So all buttons get stuck in the state they're initially shown in and changes never show up (unless a redraw is forced somehow, like by hovering over them).

If tick functions were at fault, the problem would either be GDK (and I don't think we changed anything there in 3.17) or it'd be a change in WM or windowing system behavior.

Did Anaconda change anything in that regard in rawhide compared to F22 (like switching from X to Wayland)?
Comment 6 Adam Williamson 2015-07-13 17:00:12 UTC
That's interesting - indeed, if I force anaconda to start in 'traditional installer' mode on a live image (by directly calling 'anaconda' instead of 'liveinst') so I can get into the SOFTWARE SELECTION spoke, it behaves properly. So there's some difference in the traditional installer environment. However, I'm not aware that anaconda intentionally changed anything about how it starts up between F22 and Rawhide. I'll double check with the anaconda folks.

You can see the code anaconda uses to start up its environment here:

https://github.com/rhinstaller/anaconda/blob/master/anaconda

on the 'traditional' installer images there's a systemd target 'anaconda.target' which requires a systemd service 'anaconda-direct.service' which does approximately this:

HOME=/root MALLOC_CHECK_=2 MALLOC_PERTURB_=204 PATH+/usr/bin/:/bin:/sbin:/usr GDK_BACKEND=x11 XDG_RUNTIME_DIR=/tmp /usr/sbin/anaconda

...and /usr/sbin/anaconda is that file I just pointed to.
Comment 7 Adam Williamson 2015-07-13 17:07:54 UTC
*** Bug 752200 has been marked as a duplicate of this bug. ***
Comment 8 Adam Williamson 2015-07-13 21:51:37 UTC
Narrowing down precisely when this broke is a bit tricky because Rawhide nightlies were frequently broken or not generated at all in the last few weeks. However, I have a 2015-06-07 image that boots, and it's *not* affected by this bug. So it broke somewhere between 2015-06-07 and 2015-07-04 (the earliest image I have that boots and *is* affected by the bug). So far as GTK+ goes, Rawhide went from 3.17.3 to 3.17.4 in that window.
Comment 9 Adam Williamson 2015-07-14 02:47:15 UTC
So after a bunch of bisecting it looks like a post-3.17.4 series of css changes - commits 6323010e through 8d3737e4 inclusive - fix this. Company says he can't understand why that would be, but they sure seem to do the job here in testing. I'll re-open if anything unexpected comes up.