bug#29053: 26.0.90: scroller cannot be dragged to bottom of window

bug#29053: 26.0.90: scroller cannot be dragged to bottom of window

[Charles A. Roelli]

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.

bug#29053: 26.0.90: scroller cannot be dragged to bottom of window

[Eli Zaretskii]

> Date: Sun, 29 Oct 2017 13:00:14 +0100
> From: charles@aurox.ch (Charles A. Roelli)
> 
> 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)

Almost certainly another issue.  It is best to visit the file with
find-file-literally to be sure.

> 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.

This seems to be toolkit-specific -- on MS-Windows, I see no such
issues: I can scroll to the last line and even beyond (the last
display is with EOB on the topmost line).

bug#29053: 26.0.90: scroller cannot be dragged to bottom of window

[Charles A. Roelli]

> Date: Sun, 29 Oct 2017 14:22:06 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> CC: 29053@debbugs.gnu.org
> Reply-to: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sun, 29 Oct 2017 13:00:14 +0100
> > From: charles@aurox.ch (Charles A. Roelli)
> > 
> > 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)
> 
> Almost certainly another issue.  It is best to visit the file with
> find-file-literally to be sure.

Thanks for suggesting that.  There is no scroll lag when visiting the
file literally, and the main issue introduced in this bug report
persists.

> > 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.
> 
> This seems to be toolkit-specific -- on MS-Windows, I see no such
> issues: I can scroll to the last line and even beyond (the last
> display is with EOB on the topmost line).

Under NS I had the same behavior until 26.0.90.  I will bisect to see
where the problem was introduced.

bug#29053: 26.0.90: scroller cannot be dragged to bottom of window

[Charles A. Roelli]

Seems that reverting this commit removes the issue:

  commit e683a2570be6f2e4f8defa4e7ee35a7d87f18918
  Author: Alan Third <alan@idiocy.org>
  Ref:    tags/emacs-26.0.90~2038
  Date:   Sun May 1 13:04:07 2016 +0200

  Implement horizontal scroll bars on NS

  * lisp/scroll-bar.el (horizontal-scroll-bars-available-p): Remove NS
  check.
  * lisp/term/ns-win.el: Remove custom NS scroll-bar handlers and bind
  scroll-bar mouse clicks to standard handlers.
  * src/nsterm.h (EmacsScroller): Add 'horizontal' property and rename
  pixel_height to pixel_length.
  * src/nsterm.m (x_set_window_size): Remove left-hand scroll-bar code. It
  caused scroll-bars to be over-drawn and the best working solution
  appears to be complete removal.
  (ns_set_horizontal_scroll_bar): Rewrite to handle horizontal scrollers
  correctly.
  (ns_set_vertical_scroll_bar): Set width to actual scroller width.
  (setFrame): Handle horizontal case.
  (dealloc): Handle horizontal case.
  (judge): Handle horizontal case.
  (setPosition): Rename pixel_height to pixel_length.
  (sendScrollEventAtLoc): Handle horizontal case.
  (mouseDown): Handle horizontal case and general tidy up of code.
  (mouseDragged): Handle horizontal case. Call sendScrollEventAtLoc with
  absolute pixel size instead of ratio.
  * src/window.h: Remove NS check.

macOS 10.6 is probably a special case.

bug#29053: 26.0.90: scroller cannot be dragged to bottom of window

[Alan Third]

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.

> macOS 10.6 is probably a special case.

Possibly, it seems to work fine here.

Does 10.6 have buttons to click at the top and/or bottom of the
scrollbar? If so they might affect the offset.
-- 
Alan Third

bug#29053: 26.0.90: scroller cannot be dragged to bottom of window

[Charles A. Roelli]

> Date: Wed, 1 Nov 2017 16:52:34 +0000
> From: Alan Third <alan@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.

Thanks for looking into it.

> > macOS 10.6 is probably a special case.
> 
> Possibly, it seems to work fine here.
> 
> 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.

> -- 
> Alan Third
> 

bug#29053: 26.0.90: scroller cannot be dragged to bottom of window

[Alan Third]

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@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

bug#29053: 26.0.90: scroller cannot be dragged to bottom of window

[Charles A. Roelli]

> Date: Thu, 2 Nov 2017 22:54:25 +0000
> From: Alan Third <alan@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@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.