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 617442 - GtkRange produces negative height for small windows, results in assertion failed.
GtkRange produces negative height for small windows, results in assertion fai...
Status: RESOLVED WONTFIX
Product: gtk-engines
Classification: Deprecated
Component: clearlooks
2.90.x
Other Linux
: Normal minor
: ---
Assigned To: gtk-engines maintainers
gtk-engines maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2010-05-02 13:44 UTC by Jan D.
Modified: 2014-04-05 17:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to check for negative height before calling gtk_paint_box. (985 bytes, patch)
2010-06-16 06:15 UTC, Jan D.
none Details | Review
Scrolledwindow based program to demonstrate the warning message (1.35 KB, text/plain)
2010-06-16 17:24 UTC, Jan D.
  Details
screenshot of gvim causing this message (140.24 KB, image/png)
2010-07-29 17:23 UTC, Marius Gedminas
  Details

Description Jan D. 2010-05-02 13:44:19 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:

  • #0 IA__g_log
    at gmessages.c line 568
  • #1 IA__g_return_if_fail_warning
    at gmessages.c line 584
  • #2 ??
    from /opt/gtk2.20/lib/gtk-2.0/2.10.0/engines/libmurrine.so
  • #3 IA__gtk_paint_box
    at gtkstyle.c line 6204
  • #4 gtk_range_expose
    at gtkrange.c line 1826

(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.
Comment 1 Javier Jardón (IRC: jjardon) 2010-06-16 00:23:26 UTC
Could you verify if the patch from bug #617444 fixes this problem too?
Comment 2 Jan D. 2010-06-16 06:14:31 UTC
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.
Comment 3 Jan D. 2010-06-16 06:15:32 UTC
Created attachment 163780 [details] [review]
Patch to check for negative height before calling gtk_paint_box.
Comment 4 Matthias Clasen 2010-06-16 12:06:43 UTC
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.
Comment 5 Jan D. 2010-06-16 14:44:07 UTC
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.
Comment 6 Matthias Clasen 2010-06-16 14:52:07 UTC
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.
Comment 7 Jan D. 2010-06-16 17:24:01 UTC
Created attachment 163854 [details]
Scrolledwindow based program to demonstrate the warning message
Comment 8 Jan D. 2010-06-16 17:27:33 UTC
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.
Comment 9 Tristan Van Berkom 2010-06-16 17:40:32 UTC
(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 ?
Comment 10 Tristan Van Berkom 2010-06-16 17:43:44 UTC
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.
Comment 11 Jan D. 2010-06-16 19:06:44 UTC
> 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.
Comment 12 Marius Gedminas 2010-07-29 17:23:16 UTC
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.
Comment 13 Javier Jardón (IRC: jjardon) 2010-09-05 23:48:43 UTC
(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?
Comment 14 Jan D. 2010-09-06 17:40:50 UTC
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?
Comment 15 Benjamin Berg 2010-09-06 18:50:17 UTC
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 :-)
Comment 16 Tobias Mueller 2010-11-05 02:06:03 UTC
Reopening as I guess the requested information has been provided.

FWIW: Based on comment 15, I'd say it's a GTK+ bug.
Comment 17 André Klapper 2014-04-05 17:01:53 UTC
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.