GNU bug report logs -
#29053
26.0.90: scroller cannot be dragged to bottom of window
Previous Next
Reported by: charles <at> aurox.ch (Charles A. Roelli)
Date: Sun, 29 Oct 2017 12:00:02 UTC
Severity: normal
Found in version 26.0.90
Done: charles <at> aurox.ch (Charles A. Roelli)
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#29053: 26.0.90: scroller cannot be dragged to bottom of window
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 29053 <at> debbugs.gnu.org.
--
29053: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29053
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> Date: Thu, 2 Nov 2017 22:54:25 +0000
> From: Alan Third <alan <at> idiocy.org>
>
> On Wed, Nov 01, 2017 at 09:43:46PM +0100, Charles A. Roelli wrote:
> > > Date: Wed, 1 Nov 2017 16:52:34 +0000
> > > From: Alan Third <alan <at> idiocy.org>
> > >
> > > On Tue, Oct 31, 2017 at 10:12:47PM +0100, Charles A. Roelli wrote:
> > > > (mouseDragged): Handle horizontal case. Call sendScrollEventAtLoc with
> > > > absolute pixel size instead of ratio.
> > >
> > > The problem is most likely in here.
> <snip>
> > >
> > > Does 10.6 have buttons to click at the top and/or bottom of the
> > > scrollbar? If so they might affect the offset.
> >
> > It has two buttons (up and down), at the bottom of the scrollbar.
> > When I drag the scroller as far down as possible, the distance between
> > the bottom of the scroller and the pointer (which should be zero)
> > looks about the same as the total height of the two buttons, so I
> > think you're right.
>
> It was this. Emacs expects the scroller slot to be the same number of
> pixels as the whole scroller takes up. When there are buttons within
> the scroller area then the slot is smaller.
>
> On modern macOS versions because there are no buttons the use of a
> ratio looked silly, but when there are buttons (like on GNUstep too)
> then the ratio makes more sense. I shouldn’t have changed it.
>
> I’ve pushed a fix. It works on GNUstep, so I expect it will work for
> you too.
> --
> Alan Third
Thanks very much Alan, it now works well. I'm closing the bug.
[Message part 3 (message/rfc822, inline)]
With 25.3 under macOS 10.6, from -q:
C-x C-f src/xdisp.c RET
I drag the vertical scroller from its top position (corresponding to
the start of the buffer) down to its lowest (corresponding to end of
buffer), and the mode line says "Bot L33113" and the last line of the
buffer is shown.
In comparison, when doing the same from 26.0.90 (a recent build --
4189d0e, 2017-10-29), the scrolling lags about 2 seconds behind
(possibly another issue), and I cannot bring the scroller to the
bottom of the window -- I only reach "98% L32461". Actually, the
mouse pointer tracking seems to be off by some vertical pixel offset,
such that if I click and drag the scroller, when the mouse pointer
reaches halfway down the scroll bar, the scroller is not under it, but
only 40% or 45% down.
Other ways to scroll the text up (thus bringing the scroller down
where it cannot be dragged), such as clicking in the area underneath
the scroller, and clicking the scroll bar down arrow, work fine.
This bug report was last modified 7 years and 202 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.