GNOME Bugzilla – Bug 617442
GtkRange produces negative height for small windows, results in assertion failed.
Last modified: 2014-04-05 17:01:53 UTC
If a scroll bar is small, the height GtkRange passes to gtk_paint_box may be negative, there is no check for it. This results in a message like this: ** (emacs:31140): CRITICAL **: murrine_style_draw_box: assertion `height >= -1' failed It can also be a bug in the theme, I don't know who is responsible for what. Here is a partial backtrace:
+ Trace 221661
(gdb) p range->range_rect.height $8 = 14 (gdb) p focus_line_width $9 = 0 (gdb) p focus_padding $10 = 0 (gdb) p range->has_stepper_a $11 = 1 (gdb) p stepper_size $12 = 20 (gdb) p range->has_stepper_b $13 = 0 (gdb) p range->has_stepper_b $14 = 0 (gdb) p range->has_stepper_d $15 = 1 (gdb) p stepper_spacing $16 = 0 This results in 14 - 20 - 20 = -26.
Could you verify if the patch from bug #617444 fixes this problem too?
I does not. How could it? The negative size calculation for this bug is in gtkrange.c, the fix is for gtkbox.c. Basically the theme says "My up and down arrow are y pixels high". gtkrange.c calculates the stuff in between the arrows to be window_height - 2*y. It then passes that to gtk_paint_box as height even when window_height is less than 2*y and the number becomes negative. No box involved at all. I attached a patch that fixes this bug.
Created attachment 163780 [details] [review] Patch to check for negative height before calling gtk_paint_box.
No, thats not right. If the range gets allocated too little for its drawing, then either it didn't ask for enough (bug in gtkrange) or the container did give it less than it asked for as a minimum (bug in the container). Simply not drawing is not the right fix.
I don't follow. If the user resize the top level window to be less that the height of the scrollbars two steppers, shall gtkrange ask the user to increase the height or shall gtkrange override the users resizing and force the top level window to grow? It doesn't need to be a top level window, it can be a child of a Gtk[HV]Paned.
It has been gtk policy forever that a widget can expect to be given no less space than its size request. If you want to allow users to resize your window into nothingness, then either live with the broken rendering, or stuff your content into a container that can handle this, like a scrolledwindow.
Created attachment 163854 [details] Scrolledwindow based program to demonstrate the warning message
Scrolledwindow do not handle this case. If I resize one of the panes in the attached program, the same warning is shown: ** (rangebug:2583): CRITICAL **: murrine_style_draw_box: assertion `height >= -1' failed (Funny that -1 and 0 for height is accepted). I don't think it is a user friendly thing to do to restrict the minimum pane size in these kind of layouts. Especially as the minimum size does not at all depend on something application related, like line height if it was a text based application. Instead the minimum size depends on the size of the theme scroll bar handles.
(In reply to comment #8) > Scrolledwindow do not handle this case. If I resize one of the panes in the > attached program, the same warning is shown: > > ** (rangebug:2583): CRITICAL **: murrine_style_draw_box: assertion `height >= > -1' failed > > (Funny that -1 and 0 for height is accepted). Have you tried GTK+ master ? I cant reproduce this assertion, but then maybe I don't have the same theme installed... > > I don't think it is a user friendly thing to do to restrict the minimum pane > size in these kind of layouts. Why ? Isn't it better to either hide the scroll bars altogether or at least restrict the size to the scrollbar size so the user has a chance to navigate the scrolled window content ? What other option do you need ?
Note, you could even try packing a scrolled window with the scrollbars showing into another scrolled window with hidden scrollbars - pack that into your GtkPaned... if you really want scrollbars that disappear inside your paned window minus the rendering glitch.
> Have you tried GTK+ master ? I cant reproduce this assertion, but > then maybe I don't have the same theme installed... The git version does not pull in this theme, I guess some engine is missing or not compatible. It is a theme warning and most themes don't show it. As I said initially, I don't know if it is a theme bug or Gtk+ bug. It is a new theme in Ubuntu 10.04 so this warning comes up a lot. Even Gimp shows it, and the icon I'm editing is fully visible in the (too) small Gimp window. > Isn't it better to either hide the scroll bars altogether or at least > restrict the size to the scrollbar size so the user has a chance to > navigate the scrolled window content ? Restricting the size is not something I want to do. In the two pane case, it may just be a case of shrinking one pane as much as possible and use the rest of the screen estate for the other pane. This is a common use case. It may be better to hide the scroll bars, but if only the steppers are shown, you can still scroll by clicking on them. FWIW, firefox hides the scroll bar in this case, but then again, Firefox doesn't use straight Gtk+. If even scrolledWindow doesn't handle this case well, something is missing. As for using multiple scrolled windows inside each other, that might work. But the application (Emacs) can not use scrolledWindow. I may end up hiding the scroll bar, but I do think Gtk+ should handle this itself. A critical message is overkill just because a user wants a small window.
Created attachment 166785 [details] screenshot of gvim causing this message A concrete example: gvim (see screenshot) with Ubuntu's Ambiance/Radiance themes. When you have a split window that's 1-line in heigh, there's not enough space for the scrollbar trough, which causes scary and irritating assertion messages. The scrollbar itself is fully functional (assuming there's something to scroll in that window), so as a user I'd be against hiding it. Enforcing minimum size limits is also suboptimal for the user: I want 1-line-high windows in vim, sometimes. And the theme handles it just fine: even if I set unreasonably-small font sizes like 4pt, I get two clickable scrollbar arrows. The only problem is the assertion message that spams my terminal.
(In reply to comment #11) > > Have you tried GTK+ master ? I cant reproduce this assertion, but > > then maybe I don't have the same theme installed... > > The git version does not pull in this theme, I guess some engine is missing or > not compatible. > > It is a theme warning and most themes don't show it. As I said initially, > I don't know if it is a theme bug or Gtk+ bug. It is a new theme in Ubuntu > 10.04 so this warning comes up a lot. Even Gimp shows it, and the icon I'm > editing is fully visible in the (too) small Gimp window. > Could you try with the Raleigh theme to know if It's a theme problem or not?
The Raleigh theme does not produce the warning. You could argue that the theme is in error, but what is the point of passing negative heights to the theme in the first place?
It is an engine problem in some sense. I am not sure who started it (hey, might have been me) to add these kind of error checks to theme engines. The application will still run fine even with the warning (except when passing --g-fatal-warnings). And negative sizes in a drawing function just do not make much sense. And there is also the thing that -1 is a special value (meaning the windows width/height). So, it boils down to this: 1. The warning is produced by the engine. 2. GTK+ is doing something kinda stupid by drawing something with a negative size. 3. In some rare cases (ie. when the value happens to be -1) you may get some rather surprising results. Now, obviously there two solutions that both would work to get rid of the warning. 1. Make the engines fail silently instead of printing a warning 2. Change GTK+ so it does not use a negative size Or of course: Ignore the issue :-)
Reopening as I guess the requested information has been provided. FWIW: Based on comment 15, I'd say it's a GTK+ bug.
This project is not under active development anymore (except for buildtools, the last 'real' code change happened in October 2010). According to developers, it is currently unlikely that there will be any further active development. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again.