gtk3 overlay scrollbars consistently show wrong behaviour

Bug #1516713 reported by Silvio Bierman on 2015-11-16
This bug affects 4 people
Affects Status Importance Assigned to Milestone
gedit (Ubuntu)

Bug Description

This is a general bug in GTK3 overlay scrolling (the new kind, not the old "overlay scrollbars" feature).

When a window needs both horizontal and vertical scrolling the actual accessible content is reduced by the size of the scrollbars that show up when you move the mouse into the window. Normally the scrollbars are logically outside the scrollable area and that whole are can be scrolled into view. With overlay scrolling this is not the case because the scrollbars OVERLAY the scrollable content, effectively making part of that content unreachable.

In case of a text-file opened in GEDIT this means that the last text-line will be covered by the horizontal scrollbar and you can not scroll further down to scroll it above the horizontal scroll bar (see the attached screenshot).

The fix would obviously be to extend the logical scroll range of both scrollbars with the width of the other scrollbar if that exists.

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: gedit 3.10.4-0ubuntu13
ProcVersionSignature: Ubuntu 4.2.0-18.22-generic 4.2.3
Uname: Linux 4.2.0-18-generic x86_64
ApportVersion: 2.19.1-0ubuntu4
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Nov 16 17:59:46 2015
ExecutablePath: /usr/bin/gedit
InstallationDate: Installed on 2015-11-04 (12 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
SourcePackage: gedit
UpgradeStatus: No upgrade log present (probably fresh install)

Silvio Bierman (sbierman) wrote :
summary: - gtk3 overlay scrollbars consitently show wrong behaviour
+ gtk3 overlay scrollbars consistently show wrong behaviour
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, what GTK theme are you using? The bars should be thin enough (when not in use) to not cover the text, I can't confirm the issue here...

Changed in gedit (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Silvio Bierman (sbierman) wrote :

I use numix-grey. And that does not make any sense: any scrollbar width larger than zero pixels would cover content. That could cripple any application, including one that edits graphics etc. The fact that I could access a line of text because it is larger than common scrollbar widths does not right this wrong behaviour,

Whatever the scrollbar width the calculations are off by exactly that size.

Silvio Bierman (sbierman) wrote :

Sorry, I misread your comment and the part where you said "when not in use". They are visible when the mouse is over the content so they are always "in use" when I want to click the last line to put the cursor there (which will then not work of course because I can only click on the scroll bar).

Sebastien Bacher (seb128) wrote :

> They are visible when the mouse is over the content

no, they are a thin line until the mouse is over the line, then it animates to a scrollbar, try to change your theme back to one of the default one to see....

Silvio Bierman (sbierman) wrote :

I tried Ambiance and Radience. They initially do have thinner scrollbars. But once the mouse comes close enough to the scrollbar line it extends into its full width. Only if I use a large enough font I can position the cursor in the last line. In Eclipse where I use small fonts this makes the last line of each source file inaccessible in the source editor and makes it very hard to manipulate (expand, collapse) the last item in the package tree list.

I Googled and found an environment variable I can set to disable the feature altogether and things are workable this way. But I generally don't like to resort to such obscure settings and like to keep in the mainstream. But having to pick from a rather limited set of themes to have something that kind of works is a bit too restrictive for my taste.

Sebastien Bacher (seb128) wrote :

> But once the mouse comes close enough to the scrollbar line it extends into its full width.

Right, that's how it's supposed to work

> Only if I use a large enough font I can position the cursor in the last line

you mean your fonts are smaller than the thin bar? could you add a screenshot with one of the ubuntu theme showing the issue?

Silvio Bierman (sbierman) wrote :

No, the fonts are not smaller than the line but smaller or at least hardly larger than the sensitive area (feels like about 12 pixels) near the line. As I said, you do not have to hover the line, only close enough to it.

I attached a screenshot for the Eclipse editor issue (editing a property file). For some reason it does no show the mouse cursor but I can assure you it was positioned well outside the area covered by the horizontal scroll bar. As you can see there is no way to position the cursor inside the last line (apart from using the keyboard).

Silvio Bierman (sbierman) wrote :

Btw, this was with a 9px font setting. Most of my colleagues use 8px and some have 7px but I am the senior so that is out of my league :(

Sebastien Bacher (seb128) wrote :

Ok, I see what you mean, I can't reproduce in gedit but maybe it's because the standard font is a bit bigger or maybe eclipse behaves slightly differently... (in gedit there is plenty of space to click on the char, the scrollbar just change when you hit the thin colored part at the bottom of the screen)

Changed in gedit (Ubuntu):
status: Incomplete → New
status: New → Confirmed
Silvio Bierman (sbierman) wrote :

Thank you Sebastien! If you need anyone to do some testing at any point I will be glad to help.

Devon (devonfyson) wrote :

I'm using gedit on Ubuntu 16.10 and this problem has irritated me for enough Ubuntu releases to finally complain about it. The last line at the bottom of a document is really difficult to select. The cursor so easily triggers the scroll bar instead of selecting text since the trigger area for the scroll bar overlaps by about a 1/2line overlap on the text. Same goes for the side. I think bug 808516 is similar to this bug except with the vertical scroll bar (which isn't such a problem for our left to right usage).
Same problem in Nemo and Nautilus trying to select the last file.
Firefox on the other hand forces persistent fixed width scrollbars so there is no problem there. Is there a way to get other apps to behave like Firefox?

Sebastien Bacher (seb128) wrote :

that's an upstream gtk issue and should probably be reported on

Devon (devonfyson) wrote :

Thanks, I found one already reported here

Changed in gedit (Ubuntu):
status: Confirmed → Triaged
Changed in gedit:
importance: Unknown → Medium
status: Unknown → Confirmed
Daniel van Vugt (vanvugt) wrote :

Thank you for reporting this bug to Ubuntu.
Ubuntu 15.10 (wily) reached end-of-life on July 28, 2016.

See this document for currently supported Ubuntu releases:

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed.

Changed in gedit (Ubuntu):
status: Triaged → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.