In the nice graphical version of XFdrake, when you want to change a resolution the drop down menu freezes without changing the value, the same with trying to switch between different bpps. The text version of XFdrake works fine. I've seen this in drakconnect too, when trying to change "WEP" to "WPA/WPA2 Pre-Shared Key Noticed this on a laptop and on a desktop, both 64bits, the first time was yesterday I don't remember when those drop down menus worked well for me for the last time: a week ago, two weeks.... no idea, sorry I just updated to version 16.32-1.mga5 (from 16.30.1.mga5) but that didn't make a difference Reproducible: Steps to Reproduce:
This is valid for more applications than just our own tools (for instance, when trying to change the game type in Tali, it occurs, too, and when trying to change the teletext service in ttx). In cauldron Gnome, with Adwaita, I don't see this problem when trying to adjust a resolution in (graphical) XFdrake or when changing the used teletext service, so it seems to be oxygen-gtk related. @ tv leaving this assigned to you, because it affects our tools and I don't know who else to assign to. However, feel free to reassign :-)
CC: (none) => hugo.pereiraSummary: Some DrakX drop-down menus freeze when trying to choose from them => Oxygen-gtk3: Some drop-down menus freeze when trying to choose from them.Source RPM: drakxtools-16.32-1.mga5.src.rpm => oxygen-gtk3-1.3.5-1.mga5.src.rpm gtk+3.0-3.13.2-5.mga5.src.rpm
I can confirm, with any drop list. Its actually a gtk3 bug and should be reported to them. Use any theme (Adwaita, oxygen-gtk, etc.) Add: * { -GtkComboBox-appears-as-list: 1; } To $HOME/.config/gtk-3.0/gtk.css (to use lists instead of menus in dropboxes), and you get the reported issue). In fact, "list" drop boxes has gotten more and more broken over the gtk3 releases, and there are already other bugs reported there on that matter. In the meanwhile, for using oxygen-gtk, just put "-GtkComboBox-appears-as-list: 0;" either in the $HOME file above, or in some system gtk.css (e.g. /usr/share/themes/oxygen-gtk/gtk-3.0/gtk.css) We (oxygen) will not put that fix upstream, sorry. Lists is what we want to use, for consistency with Qt, and gtk should fix the issue (or drop the feature, to force us not to use it), but in any case not provide broken features. Hugo
CC: (none) => thierry.vignaudAssignee: thierry.vignaud => olavSource RPM: oxygen-gtk3-1.3.5-1.mga5.src.rpm gtk+3.0-3.13.2-5.mga5.src.rpm => gtk+3.0-3.13.2-5.mga5
For completeness, patch to oxygen-gtk3 package that work-around the issue, in case someone wants to include it while waiting for a proper upstream fix. diff --git a/rc/gtk.css b/rc/gtk.css index a76cb62..f6450bb 100644 --- a/rc/gtk.css +++ b/rc/gtk.css @@ -53,7 +53,7 @@ INFO: css border and padding ordering is either: -GtkButton-default_border: 0px; -GtkButton-default_outside_border: 0px; - -GtkComboBox-appears-as-list: 1; + -GtkComboBox-appears-as-list: 0; -GtkMenu-horizontal-offset: -7px; -GtkMenuBar-internal-padding: 0px;
Fixed with gtk+3.0-3.13.3-1.mga5
Status: NEW => RESOLVEDResolution: (none) => FIXED
not fixed entirely here, at least Warning: here at least, following freezes the DM. open gtk3-demo, select Combo Boxes, try change any of the seen combobox, desktop freezes (because of a mouse grab that is never released) Happens with any widget style as soon as -GtkComboBox-appears-as-list: 1;
Marja, do you want to push the comment #3 workaround in oxygen-gtk3? Else I'll do it tonight in ~12 hours
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
PS: there are a number of other issues with oxygen-gtk3 and this new gtk3 version, most annoying (to me) being "double" shadows for menus in KDE. (one drawn by gtk3 and one by kwin) I have fixed this locally, as well as other things, and should be able to make a new release sometime next week.
(In reply to Hugo Pereira Da Costa from comment #5) > open gtk3-demo, select Combo Boxes, try change any of the seen combobox, > desktop freezes (because of a mouse grab that is never released) Is this a gtk+ issue or a Oxygen one? If gtk+, please just mention the upstream bugnumbers here or on dev@ and I'll push for fixes.
It seems to be a gtk+3 issue that oxygen-gtk3 can workaround by disabling some features (see comment #2)
A mouse grab sounds way worse than all the other bits. But I need bugnumbers to do anything.
I'm not aware of any. But I confirm that my desktop is regularly frozen with the mouse stuck in grab mode and I can only kill the session from tty2
gtk+ got stuck also when resizing drakbug...
Source RPM: gtk+3.0-3.13.2-5.mga5 => gtk+3.0-3.13.3-1.mga5
(In reply to Thierry Vignaud from comment #6) > Marja, do you want to push the comment #3 workaround in oxygen-gtk3? > Else I'll do it tonight in ~12 hours Sorry, even if I had been around, I couldn't have pushed it: I'm just a padawan (without time to learn what's needed to be a full packager).
Olav, gtk+3 is unusable. desktop is stuck once I try to move/resize a window...
@Thierry Really ? with any widget style ? I can't reproduce here (but compiled latest gtk+3 3.13.3 from source, because I'm still on mageia 4)
@Thierry (again) Does it happen with all applications ? The one with "native" server side decorations (e.g. gedit, evince) Or only the one with client side decorations (e.g. nautilus)
I've only tested oxygen but this is all new since gtk+-3.13.3 (3.13.2 was not that buggy). Yes all applications: gnome-terminal, gnome-control-center, drakbug, ... I've to remember going through the right click contextual menu in order to maximize a window else mouse got stuck. My wife is seeing the same.
Priority: Normal => HighSeverity: normal => critical
firefox too...
I finally found out I need to click on "run" to do the gtk3-demo Combo Boxes test... hadn't seen that button :-[ Yes, before installing oxygen-gtk3-1.3.5-2.mga5 it freezes on all of them, even if, after gtk+3.0-3.13.3-1.mga5 I don't see this problem anywhere else any more on two different 64bits cauldron machines (but only checked in KDE) Installing oxygen-gtk3-1.3.5-2.mga5 solves it here for the gtk3-demo Combo Boxes, too (again in KDE). I can only reproduce Thierry's problems in Gnome. For me, that is with the Adwaita theme.
For me, it happens with both Adwaita & Oxygen. Note that I'm using classic gnome, not regular gnome (I'm old fashion)
For me it was with Gnome3
and, to be more clear, for Gnome I *only* tested with Gnome3 and Adwaite
updating mutter>gnome-shell>gnome-shell-extensions seems to have fixed gnome classic keeping being stuck on mouse events
(In reply to Thierry Vignaud from comment #23) > updating mutter>gnome-shell>gnome-shell-extensions seems to have > fixed gnome classic keeping being stuck on mouse events Same for Gnome3 Closing this report again. Feel free to reopen if there is still an issue related to the gtk+3.0 and/or the oxygen-gtk3 update.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
My wife still saw some freeze (but they now happen quite less often Olav I think you should backport this one: https://git.gnome.org/browse/gtk+/commit/?id=fe5402d32ebf7f332a2c5f71b9ae50dcf68892fd "gtkcellrendereraccel: Use a GtkInvisible to grab onHEADmaster Grabbing on a non-toplevel might not do what we want it to do, since it will go on the focused widget, not the grabbed widget. Since we don't focus the widget before clicking on it, that means that putting the focus somewhere else and then clicking on the accelerator editor will freeze the app. Additionally, since it's a global system grab that can't be exited except by a key press that we won't ever get, it effectively locks up your system as well unless you know how to break the grab or kill the app. Ouch. Since doing a device grab on a non-toplevel is generally considered a bad idea, just don't do it. Use a GtkInvisible and take a grab on that instead. "
Patch referenced in comment 25 added in gtk+3.0-3.13.3-4.mga5
Status: REOPENED => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
FYI: http://download.kde.org/stable/oxygen-gtk3/1.4.0/src/oxygen-gtk3-1.4.0.tar.bz2 Should work better with latest gtk3 Don't hesitate to cc me on any bug that would look oxygen-gtk3 related. Hugo
I've submitted 1.4.0. Following still needed? + -GtkComboBox-appears-as-list: 0; Any bug in gtk+3.0 itself?
Hi Olav, thanks for submitting. concerning patch, no it should not be needed, assuming that changes from coment #25 and #26 work as expected.