Created attachment 448361 [details] Screenshot of the reproducer snippet, with enabled scrollbar steppers and disabled overlay scrollbars. Description of problem: The following theme code breaks WebKit horizontal scrollbars: * { -GtkScrollbar-has-backward-stepper: true; -GtkScrollbar-has-forward-stepper: true; } Version-Release number of selected component (if applicable): Red Hat Enterprise Linux release 9.0 Beta (Plow) gtk3-3.24.30-3.el9.x86_64 webkit2gtk3-2.32.3-2.el9.x86_64 How reproducible: Run snippet provided below. Steps to Reproduce: 1. Adjust the user .css to enable scrollbar steppers (create a backup beforehand if user .css already exists): echo "* { -GtkScrollbar-has-backward-stepper: true; -GtkScrollbar-has-forward-stepper: true; }" > ~/.config/gtk-3.0/gtk.css 2. Create an .html file to display "overlay_scroll.html", with contents: <!DOCTYPE html> <html> <head> <style> div.scroll { margin: 4px, 4px; padding: 4px; width: 500px; overflow: scroll; } </style> </head> <body> <div class="scroll"> "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum." </div> </body> </html> 3. Create the GTK3 snippet "browser.cpp" with contents: #include <gtk/gtk.h> #include <webkit2/webkit2.h> static void destroyWindowCb(GtkWidget* widget, GtkWidget* window); static gboolean closeWebViewCb(WebKitWebView* webView, GtkWidget* window); // gcc -g browser.cpp `pkg-config --cflags --libs webkit2gtk-4.0 gtk+-3.0` -o BrowserExample && ./BrowserExample int main(int argc, char* argv[]) { // Initialize GTK+ gtk_init(&argc, &argv); // Create a window that will contain the browser instance GtkWidget *main_window = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_window_set_default_size(GTK_WINDOW(main_window), 300, 200); // Create a browser instance WebKitWebView *webView = WEBKIT_WEB_VIEW(webkit_web_view_new()); // Put the browser area into the main window gtk_container_add(GTK_CONTAINER(main_window), GTK_WIDGET(webView)); // Set up callbacks so that if either the main window or the browser instance is // closed, the program will exit g_signal_connect(main_window, "destroy", G_CALLBACK(destroyWindowCb), NULL); g_signal_connect(webView, "close", G_CALLBACK(closeWebViewCb), main_window); // Load a web page into the browser instance webkit_web_view_load_uri(webView, "file:///home/sandreev/overlay_scroll.html"); // Make sure that when the browser area becomes visible, it will get mouse // and keyboard events gtk_widget_grab_focus(GTK_WIDGET(webView)); // Make sure the main window and all its contents are visible gtk_widget_show_all(main_window); // Run the main GTK+ event loop gtk_main(); return 0; } static void destroyWindowCb(GtkWidget* widget, GtkWidget* window) { gtk_main_quit(); } static gboolean closeWebViewCb(WebKitWebView* webView, GtkWidget* window) { gtk_widget_destroy(window); return TRUE; } 4. Run the snippet with command line: gcc -g browser.cpp `pkg-config --cflags --libs webkit2gtk-4.0 gtk+-3.0` -o BrowserExample && ./BrowserExample Actual results: The horizontal scrollbar is not displayed correctly. When overlay scrollbars are disabled, the horizontal scrollbar is undersized/misplaced, and a thick black bar is displayed above it. When overlay scrollbars are enabled, the horizontal scrollbar is undersized/misplaced. It looks like the horizontal scrollbar is drawn too low, but its hard to tell. Expected results: The horizontal scrollbar is displayed correctly. Additional info: RHEL bugzilla ticket: https://bugzilla.redhat.com/show_bug.cgi?id=2037016 Found while investigating Eclipse bug for JavaDoc/debugging hovers with GTK3: https://bugs.eclipse.org/bugs/show_bug.cgi?id=546961
Created attachment 448362 [details] Recording of the reproduction snippet, if scrollbar steppers and overlay scrollbars are enabled.
I notice that Epiphany and MiniBrowser are both always fine, even if opened directly with very small window size, but your reproducer always exhibits the bug. This is... hard to explain.
Created attachment 449604 [details] gfeeds screenshot of same issue It happens in gfeeds. I'm struggling to figure out what makes it different from MiniBrowser, but I suppose it doesn't matter, so long as I'm able to reproduce it somehow.
As a workaround, you can turn off WebKitWebContext:use-system-appearance-for-scrollbars, though you'll lose the steppers altogether. (Note this setting will become forced in the future, in the GTK 4 API version, since GTK 4 doesn't provide any way for us to draw scrollbars that look like its own.)
(In reply to Michael Catanzaro from comment #4) > As a workaround, you can turn off > WebKitWebContext:use-system-appearance-for-scrollbars, though you'll lose > the steppers altogether. (Note this setting will become forced in the > future, in the GTK 4 API version, since GTK 4 doesn't provide any way for us > to draw scrollbars that look like its own.) Is this added to the .html page? Or are there other options (e.g. per API call, or maybe some central configuration file per user)? Ideally, could you give an example or a link to some documentation page? I have almost 0 knowledge on WebKit use and its use in SWT/Eclipse.
That's a GObject property of the WebKitWebContext object, e.g.: context = webkit_web_view_get_context(webView); webkit_web_context_set_use_system_appearance_for_scrollbars(context, FALSE); Anyway, as for a real solution, I've been staring at ScrollbarThemeGtk.cpp, but I haven't found the problem yet. I've never understood the drawing code very well. It looks like the vertical scrollbars are broken too, but the problem there is much simpler: with vertical scrollbars, only the steppers are in the wrong position, and only by a small amount. So that seems like an easier related issue to start with....
Thanks, will try the workaround with Eclipse next week.
(In reply to Michael Catanzaro from comment #6) > That's a GObject property of the WebKitWebContext object, e.g.: > > context = webkit_web_view_get_context(webView); > webkit_web_context_set_use_system_appearance_for_scrollbars(context, FALSE); Seems to work on RHEL 9, for the snippet from the description. For some reason "webkit_web_context_set_use_system_appearance_for_scrollbars" is not found on RHEL 7.9, webkitgtk3-2.4.11-2.el7.x86_64. For https://bugs.webkit.org/show_bug.cgi?id=234874, the workaround doesn't help (no idea if the 2 bugs are related in any way, Eclipse seems to be affected mostly by bug 234874).
(In reply to Simeon Andreev from comment #8) > For some reason > "webkit_web_context_set_use_system_appearance_for_scrollbars" is not found > on RHEL 7.9, webkitgtk3-2.4.11-2.el7.x86_64. Well that's no mystery: WebKitGTK 2.4 was released in 2014, but this API was added last year in WebKitGTK 2.30. (Note the "webkitgtk3" package has been deprecated for a very long time. RHEL 7 also provides a newer "webkitgtk4" package, containing WebKitGTK 2.28, which is equivalent to the "webkit2gtk3" package in 8 and 9.) > For https://bugs.webkit.org/show_bug.cgi?id=234874, the workaround doesn't > help (no idea if the 2 bugs are related in any way, Eclipse seems to be > affected mostly by bug 234874). I'm only slightly surprised. Haven't looked closely at that one yet, but whatever is going wrong in that bug is more severe than just drawing things in the wrong position, like we have here....
Are you content with this workaround? I will leave this bug open, because it's clearly a mistake in the drawing code that we should fix. But if you're OK with using the workaround for now, then I will prioritize bug #234874 instead.
(In reply to Michael Catanzaro from comment #10) > Are you content with this workaround? > > I will leave this bug open, because it's clearly a mistake in the drawing > code that we should fix. But if you're OK with using the workaround for now, > then I will prioritize bug #234874 instead. We have a added a workaround in Eclipse to not display scrollbars and to use wrapping instead (for the most obvious cases, not for all). So yes, please focus on bug 234874; that one seems to be a bigger issue.
Created attachment 451519 [details] Patch
Comment on attachment 451519 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=451519&action=review > Source/WebCore/platform/gtk/RenderThemeScrollbar.cpp:110 > - m_contents = makeUnique<RenderThemeBoxGadget>(info, GTK_ORIENTATION_VERTICAL, children, m_scrollbar.get()); > + m_contents = makeUnique<RenderThemeBoxGadget>(info, orientation, children, m_scrollbar.get()); Wow, thanks.
Committed r289529 (247060@main): <https://commits.webkit.org/247060@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 451519 [details].
The steppers are still mispositioned, so I've retitled this bug to reflect that that part is not fixed.
Mispositioned how? It looked fine in local testing.
Created attachment 451571 [details] Screenshot
(In reply to Alexander Mikhaylenko from comment #16) > Mispositioned how? It looked fine in local testing. The steppers are mispositioned when NOT hovering the overlay scrollbar. I can post a screenshot soon if you really don't see it.
Ah, I see now. I was testing with disabled overlay scrollbars, same as the other bug. My bad.
Reopening.
Unfortunately, it looks like I'll need help with building WebKit. I have a fresh CentOS 9 installation in a VM (my RHEL 9 workstation is missing some repositories and so some libraries). To configure the build, I ran: cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -DUSE_SOUP2=ON -DUSE_WPE_RENDERER=OFF -DENABLE_GAMEPAD=OFF -GNinja When I run 'ninja', there is an error: [sandreev@localhost WebKit]$ ninja ninja: error: '/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml', needed by 'WebKit2Gtk/DerivedSources/pointer-constraints-unstable-v1-protocol.c', missing and no known rule to make it This is on wayland, if it makes a difference. What do I need to fix the above?
(In reply to Simeon Andreev from comment #21) > When I run 'ninja', there is an error: > > [sandreev@localhost WebKit]$ ninja > ninja: error: > '/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml', needed > by 'WebKit2Gtk/DerivedSources/pointer-constraints-unstable-v1-protocol.c', > missing and no known rule to make it > > > This is on wayland, if it makes a difference. > > What do I need to fix the above? Never mind, looks like I needed to also install: wayland-protocols-devel (judging from this commit: https://cgit.freebsd.org/ports/commit/?id=64cd9b834640d880d8bb0cd083d2e4cdf365eec6)
Note the packaging is all public: https://gitlab.com/redhat/centos-stream/rpms/webkit2gtk3. The easiest way to build is to clone that repo then run 'centpkg mockbuild'.
(In reply to Alexander Mikhaylenko from comment #20) > Reopening. It's really a separate issue, so I'm going to close this again as the main problem here is fixed. Let's use bug #236503 to track the issue with mispositioned steppers.
Thanks, next week I'll check the fix for this bug and bug 234874 in Eclipse.
See also: bug #227841
Created attachment 451872 [details] Screen recording with and without fixes on RHEL 9. Same as with bug 234874, I see double scrollbars (here, with the snippet .html from the description). See also bug 234874 comment 26 and bug 234874 comment 27. Is this "normal"?
(In reply to Simeon Andreev from comment #27) > Created attachment 451872 [details] > Screen recording with and without fixes on RHEL 9. > > Same as with bug 234874, I see double scrollbars (here, with the snippet > .html from the description). See also bug 234874 comment 26 and bug 234874 > comment 27. > > Is this "normal"? Eclipse looks fine, but there the "overflow:scroll" seems to be ignored, word wrap is used instead (regardless of what the .html specifies, with and without the fix); so the bottom horizontal scrollbar is never usable (in Eclipse).
Let's discuss the double scrollbars in a new bug. I can't reproduce, but I guess it's probably triggered by either the margin or the padding.
Actually, let's discuss that in bug #234874.
On RHEL 9, webkit2gtk3-2.34.6-1.el9.x86_64 has the fix. Validated with it. Thank you for fixing this!