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 407886 - scrollbar not always displayed when result is too large
scrollbar not always displayed when result is too large
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkScrolledWindow
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
scrolling
Depends on:
Blocks:
 
 
Reported: 2007-02-14 15:13 UTC by Teppo Turtiainen
Modified: 2018-05-02 14:28 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
screenshot of the problem (10.92 KB, image/png)
2007-02-14 15:14 UTC, Teppo Turtiainen 		Details
screenshot (15.25 KB, image/png)
2018-03-15 16:47 UTC, Teppo Turtiainen 		Details

Description Teppo Turtiainen 2007-02-14 15:13:59 UTC 
The scrollbar is not displayed when the results is just slightly larger then the window.

Steps to reproduce:
1. Press 1 sixteen times in Basic mode.

Please see attached screenshot.
Comment 1 Teppo Turtiainen 2007-02-14 15:14:35 UTC 
Created attachment 82540 [details]
screenshot of the problem
Comment 2 Rich Burridge 2007-02-15 05:41:04 UTC 
This looks like it's font specific. I can enter in 1's in Basic
mode and the scrollbar is displayed the moment one of them isn't
totally visible.
Comment 3 Teppo Turtiainen 2007-02-15 08:03:48 UTC 
Yes, seems to depend on the font used, but I can reproduce this with several different fonts.
Comment 4 Rich Burridge 2007-02-15 15:48:32 UTC 
Understood. It's a bug. I doubt whether I'll get to fixing it for
GNOME 2.18. I'm concentrating on my Orca work at the moment. Of
course, if there was a patch attached to the bug, then that might be
different... 8-)

I spent a couple minutes on it. The code is in .../gcalctool/gtk.c
The scrollwindow has (about line 1004):

        gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(sw),
                                       GTK_POLICY_AUTOMATIC,
                                       GTK_POLICY_NEVER);

I'm guessing that the policy needs to be adjusted.
Or that there is an underlying GTK+ bug here.
Comment 5 Christian Persch 2007-09-21 18:41:40 UTC 
I think this is a gtk bug and should be re-assigned to gtk+. I also noticed that the cursor disappears in this case if you move it to be in front of the string.
Comment 6 Rich Burridge 2007-09-21 19:02:32 UTC 
Thanks Christian. Reassigning...
Comment 7 Rich Burridge 2008-02-07 23:39:39 UTC 
*** Bug 515094 has been marked as a duplicate of this bug. ***
Comment 8 Teppo Turtiainen 2014-11-22 17:59:46 UTC 
Still happens with gtk+ 3.14.5 on Fedora 21.
Comment 9 Matthias Clasen 2018-02-10 05:06:13 UTC 
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 10 Teppo Turtiainen 2018-03-15 16:47:21 UTC 
Created attachment 369748 [details]
screenshot

Other weirdness happens now.
Comment 11 GNOME Infrastructure Team 2018-05-02 14:28:03 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/277.