When using GTK3 apps with the oxygen-gtk theme, scrolling with the mouse wheel does not have any effect. Besides a large text field, this also happens with a combobox. Initially reported at https://bugs.archlinux.org/task/35348 for gtk3. Tested with Arch Linux package 1.1.4-1 and gtk3 branch @ 97b78c3e022fa154373e674ad0f5117a41026bc9. Reproducible: Always Steps to Reproduce: 1. Run oxygen-gtk3-demo 2. On the "Input widgets" tab, scroll with the pointer on "Multi-line text editor", "Editable combobox" 3. On the "Tab widgets" tab, scroll with the pointer on "First tab" and the drop-down box containing "North" Actual Results: The widgets do not change state, the values are not visually modified. Expected Results: The contents of the text view labelled the "Multi-line text editor" should be scrolled, the "Editable combobox" should change from "First item" to "Second item" or "Third item", different tabs on the "Tab widgets" page should be activated, drop down boxes should change value (e.g. North -> South/West/East). Just like oxygen-gtk-demo (which uses gtk2)
Created attachment 80588 [details] textview scroll fix Based on http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2f1ae4577dc2ebb8f48083edff797d352d1b47ca This patch resolves scrolling issue in the text view, the tabs, comboboxes, etc. are still affected.
Thanks for the bug report and the proposed patch, will test and add as soon as we can confirm the bug and the fix. Will keep you posted.
Does https://developer.gnome.org/gtk3/3.5/gtk-migrating-2-to-3.html (more specifically, https://developer.gnome.org/gtk3/3.5/ch24s02.html#idp129733824 ) help? For clarity (my previous comment was ambigious), the tabs, comboboxes and drop-down (select) widgets are still not scrollable.
Testing a bit: on the multiline text editor, I cannot reproduce. (usign gtk-3.6.4) on comboboxes (editable or not), I can reproduce the issue, with oxygen-gtk3, but then the same issues persists with other widget styles (namely adwaita). (and besides, I don't think our code alters anything about scroll behavior) So this would be an issue with either - oxygen-gtk3-demo (no big deal) - gtk3 itself. So the questions: 1/ what is your gtk version ? 2/ can you confirm that the issues with comboboxes and tabbars is present with other applications that run gtk3 (and which ones) ? 3/ can you confirm that the issues with comboboxes and tabbars are fixed if you use another widget style, and which one ? Thanks, Hugo
Ah, of course, I forgot to mention some details: GTK 3.8.2 Scrolling issue in text field is also present in gtk3-demo-application (type something and make sure a scrollbar appears, then try to scroll). Initially noticed the bug in wireshark 1.10.0. The Default and Emacs GTK3 theme do not show the issue. (selected in System Settings -> Application Appearance -> GTK, GTK Themes, Select a GTK3 Theme). When editing ~/.config/gtk-3.0/settings.ini directly, commenting `gtk-theme-name=oxygen-gtk` also fixes the scrolling issue for obvious reasons.
for editors, ok. I'll check with 3.8 (which breaks other things in oxygen-gtk last time I checked, like pretty much every single new release of gtk3). what about comboboxes ? is the bug present, or not, with other themes ?
With Default, Emacs and Oxygen on GTK3: - Keep pointer on the "First item" text and scroll -> nothing happens - Keep pointer on the tab bar and scroll -> nothing happens With both Default and Emacs on GTK3, I get the following behavior: - Keep pointer on the arrow button (on the right) and scroll -> changes items as expected (on Oxygen, nothing happens)
@comment #7 ok. I can also reproduce this (even with gtk 3.6) I'll investigate.
Some updates: 1/ for comboboxes (both read-only and editable), this is actually a gtk bug. If you edit /usr/share/themes/oxygen-gtk/gtk-3.0/gtk.css to change -GtkComboBox-appears-as-list: 1; into: -GtkComboBox-appears-as-list: 0; You will get the activation on mousewheel working again (but combobox lists will appear as menus, which we do not want. So this should be reported to gtk3 folks (possibly with link to this post) 2/ for tabbars: seems to be a gtk3 bug also: mouse wheel is not working for switching tabs in oxygen-gtk3-demo for any widget style I have tried (oxygen-gtk, Adwaita, Raleigh. So should be reported there also; 3/ for multiline text editor: I have had no time yet to test with gtk-3.8 (nor test your patch). But I cannot reproduce the issue with gtk-3.6 Please confirm points 1 and 2.
1) Correct. One observation with the current situation (where -GtkComboBox-appears-as-list: 1px;), after closing the menu I see: (oxygen-gtk3-demo:6154): Gdk-CRITICAL **: gdk_device_ungrab: assertion `GDK_IS_DEVICE (device)' failed (oxygen-gtk3-demo:6154): Gtk-CRITICAL **: gtk_device_grab_remove: assertion `GDK_IS_DEVICE (device)' failed (oxygen-gtk3-demo:6154): Gdk-CRITICAL **: gdk_device_ungrab: assertion `GDK_IS_DEVICE (device)' failed (oxygen-gtk3-demo:6154): Gtk-CRITICAL **: gtk_device_grab_remove: assertion `GDK_IS_DEVICE (device)' failed 2) Yep, I mentioned this in a previous comment. It is a regression in gtk 3.8. 3) The text field scrolling problem does not exist in GTK 3.6.4 (built from git) in combination with oxygen-gtk. I do see a black background though and a complaint: (oxygen-gtk3-demo:7411): Gtk-WARNING **: Theme parsing error: gtk.css:80:22: Theming engine 'oxygen-gtk' not found (tab scrolling and menu in oxygen is still broken) I even tried 3.5.18 in which tabs scroll still does not work with the default theme (and oxygen-gtk). Reported at https://bugzilla.gnome.org/show_bug.cgi?id=702663
Not sure if this is the same bug, but I'm having scrolling issues in some parts of Evolution under KDE in Fedora 19. I've discussed this with the Evolution developers and their opinion is that the problem appears to originate in KDE. evolution-3.8.4-2.fc19.i686, KDE 4.10, gtk3-3.8.2-2.fc19.i686, gtkhtml3-4.6.6-1.fc19.i686 My wireless mouse scroll wheel works everywhere except in the Evo folders pane, i.e. everywhere else in my desktop (KDE), and in the Evo message pane and preview pane. Scrolling the folders pane works correctly using my laptop touchpad, or dragging the scroll bar with the mouse. Clicking on a folder name before scrolling makes no difference. Here's the relevant comment: https://bugzilla.gnome.org/show_bug.cgi?id=699574#c16
(In reply to comment #1) > Created attachment 80588 [details] > textview scroll fix > > Based on > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=2f1ae4577dc2ebb8f48083edff797d352d1b47ca > > This patch resolves scrolling issue in the text view, the tabs, comboboxes, > etc. are still affected. I gave this patch a try with my GTK 3.8.2 and it fixed the scrolling regression in Audacious. Though, Nautilus 3.8.2 is still affected: scrolling with mouse scroll doesn't work at all unless I hover the scroll bar ifself; scrolling with touchpad is OK. These problems were not present in GTK 3.6.
I can confirm the scrolling issue with oxygen-gtk 1.1.4 (gtk3 3.8.2). Scrolling in Wireshark does not work properly when using the oxygen GTK3 style, while it works fine for other styles (I tried Adwaita). Interesting enough, whether scrolling works or not depends on the mouse I use: With the touchpad two-finger scrolling, it works, but a USB mouse attached to my laptop doesn't scroll properly.
With oxygen-gtk3 1.2.0 (GTK 3.8.4), the scrolling bug in Wireshark (1.10.1) can still be reproduced. Like Ralf, I can observe that two-finger scrolling works on my laptops Synaptics touchpad. Scrolling is still broken [for the wheel] on my Logitech M525 mouse and [with two finger scrolling] on a Logitech T650 touchpad. (both devices are connected wireless to a USB receiver). Another note, scrolling using these two Logitech devices can still be done by keeping the mouse pointer on the scrollbar. (odd, the status of this bug is still "UNCONFIRMED")
I can confirm the scrolling works with touchpad (one or two finger is not relevant) but not with the mouse wheel. this behaviour happens not only with wireshark but also with other gtk-software like the player audacious
comment #14 Unconfirmed because, I cannot reproduce. (same version of oxygen-gtk3, gtk3 and wireshark) With either touchpad or standard mouse, I can scroll wireshark's main page, from anywhere on the page, using mouse weel or two fingers. (so makes it hard for me to investigate the issue) Just one wild guess, can someone try to compile oxygen-gtk from scratch with option "-DENABLE_INNER_SHADOWS_HACK=0" ? and see if problem persists ?
No need to recompile - just try environment variable OXYGEN_DISABLE_INNER_SHADOWS_HACK=0.
I can confirm that setting the OXYGEN_DISABLE_INNER_SHADOWS=0 env avoids the bug. Tested with oxygen-gtk3-demo from Arch Linux package oxygen-gtk3 1.2.0-1 (unpatched).
I cannot confirm this here, the environment variable does not change anything. I'm using oxygen-gtk 1.1.4 and gtk3 3.8.4.
(In reply to comment #16) > comment #14 > Unconfirmed because, I cannot reproduce. > (same version of oxygen-gtk3, gtk3 and wireshark) > With either touchpad or standard mouse, I can scroll wireshark's main page, > from anywhere on the page, using mouse weel or two fingers. (so makes it > hard for me to investigate the issue) > > Just one wild guess, > can someone try to compile oxygen-gtk from scratch with option > "-DENABLE_INNER_SHADOWS_HACK=0" ? and see if problem persists ? Are you able to scroll the packet list while wireshark is running in capturing mode? Because, yes, the main screen is scrollable with the mouse but not the packet list.
@Francesco yes, this I can reproduce (precise bug description always helps. Thanks !) And indeed OXYGEN_DISABLE_INNER_SHADOWS_HACK=1 fixes the issue here (and likely the other issues). I'm afraid this is an upstream bug then. Problem with "composite" windows. Will investigate some more and unfortunately close the bug if this is confirmed. Still if this is the case, I'll open a gtk3 but with a simple test case. @ralf there was a typo in Ruslan's comment: OXYGEN_DISABLE_INNER_SHADOWS_HACK=1 should be the right setting. Can you check again ?
More explicitely, in bash: OXYGEN_DISABLE_INNER_SHADOWS_HACK=1 wireshark Also,, I bet this should fix the issue with the other applications also. Please double-check.
yes, it works for me I have tried OXYGEN_DISABLE_INNER_SHADOWS_HACK=1 wireshark and OXYGEN_DISABLE_INNER_SHADOWS_HACK=1 audacious and for both the fix solves the bug
I made a typo, it should be: OXYGEN_DISABLE_INNER_SHADOWS_HACK=ducks-can-fly oxygen-gtk3-demo The code only checks for !getenv("OXYGEN_DISABLE_INNER_SHADOWS_HACK"), so the value does not matter, only if it's set or not.
Confirmed with "OXYGEN_DISABLE_INNER_SHADOWS_HACK=1 wireshark" the bug is indeed gone. Hugo, if it turns out to be an upstream bug - could you report it upstream? I'd do it as well, but you are probably more competent to actually tell them what's breaking scrolling.
I reported a bug a while ago for GTK+ https://bugzilla.gnome.org/show_bug.cgi?id=702663
(In reply to comment #26) > I reported a bug a while ago for GTK+ > https://bugzilla.gnome.org/show_bug.cgi?id=702663 As far as I know, that's a different issue. Not the one that is fixed by disabling shadow hack, that is related to composite windows.
(In reply to comment #25) > Confirmed with "OXYGEN_DISABLE_INNER_SHADOWS_HACK=1 wireshark" the bug is > indeed gone. > > Hugo, if it turns out to be an upstream bug - could you report it upstream? > I'd do it as well, but you are probably more competent to actually tell them > what's breaking scrolling. Yes I'll do. I plan to write a test app (main.c) that exposes the bug independently from oxygen-gtk before posting to gtk+, to make sure the issue is not bounced back (which is often the case). Will put a link to the gtk+ bug here before closing.
Created attachment 82457 [details] simple test code that exposes the compositing bug independently from oxygen-gtk
(In reply to comment #29) > Created attachment 82457 [details] > simple test code that exposes the compositing bug independently from > oxygen-gtk untar, build, using cmake You should be able to reproduce the issue with scrolling whatever widget style is used (in fact this is even worse with oxygen-gtk, but that's a different issue) you can "fix" the issue by editing the "c" file and comment out the part about "compositing". Can someone give it a shot and confirm ? I plan to post that as a gtk bug
link to the upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=708570 Closing this one. Hope this will get fixed. In the meanwhile please use the "no_shadows_hack" solution above.
(In reply to comment #30) > Can someone give it a shot and confirm ? > I plan to post that as a gtk bug Confirmed with the Adwaita style, it behaves exactly as you describe - scrolling is broken unless I change the "if (1 )" to "if ( 0 )". Thanks a lot!