When using IDLE on OS X and scrolling to the bottom of a file you are not able to scroll using a mouse back up. You need to use the arrow keys.

I think I am able to reproduce that behavior (I'm using IDLE from a python.org 10.9+ installer).  What I'm seeing is that if you scroll to the bottom of a file that exceeds the length of the open text window and then click on and try to move the position indicator in the scroll bar, the position indicator does not move nor does the file scroll.  But if I then click elsewhere in the scroll bar and then try to grab and move the indicator, it works OK.  So perhaps IDLE is overriding a text widget event or some such.  FWIW a quick test in the wish8.6 text demo seems to work OK.

There are 3 ways to scroll by key in each direction: Arrow Down/Up, Page Down/Up, and Cntl End/Home.  There are 4 ways to scroll by mouse, in each direction: Mousewheel down/up, Scrollbar arrow bottom/top (== Arrow keys), Scrollbar trough below/above slider (= Page keys), and Scrollbar slider.

On Windows, if I Load Module idlelib.editor and go to the bottom, with the text cursor on the last line, all up methods work.  Bruce, which of the four mouse up methods don't work for you?  Just grabbing the slider, as Ned found?  What happens is you move the slider down, and try to move up without releasing the button?

Cheryl or Tal, can one of you check on Linux?

In the text area, the mouse pointer, for me, is a vertical bar and the slider is a light gray.  When I move the mouse over the scrollbar slider, the slider become active and ready to click on.  The indication is that the mouse pointer becomes an arrow pointing up left and the slider turns dark gray.  When the mouse is over the scrollbar trough or arrows, the slider only darkens to medium gray.  When over an arrow, the arrow darkens. Bruce, do you see the 'activation' change when the slider is at the bottom and you mouse over it, but cannot grab it?


In May, we changed the 3.6+ editor text/mousewheel/scrollbar interaction a bit so that the text scrolled by lines, rather than by pixel. #33664, PR 7351. There is always a complete line at the top -- unless one changes the window height to a non-integral number of lines and moves the cursor to the last line.  (Then the complete lines are at the bottom until one moves the cursor to the top line  -- Cheryl, we should try to fix this.)

The patch changed the command function that the scrollbar calls when it is clicked or the slider is moved to editor.EditorWindow.handle_yview. The new function has an extraneous "return 'break'" that can and should be removed.  But I doubt that is the problem.  It also has new code that is only executed for slider movements.

If only the slider has a problem and this slider code were to raise when at the bottom, we might have an explanation.  I am dubious, as the only possible platform-specific calls are the tkinter calls text.index('end') and text.index('@0.0').  To check this anyway, please start IDLE in the Mac terminal with 'python3 -m idlelib'  (correct on Mac?) and repeat the failing action and see if a traceback appears.

It might also help to know if 2.7 or 3.5- have the same problem.

2.7.15 scrolling is working just fine.

1 down, but how about my other questions?
Is there only a problem if the slider is the first thing touched?
Is there still a problem if the line "return 'break'" in idlelib.editor.EditorWindow.handle_yview is deleted or disabled by prefixig it with '#'?  (Are you allowed to edit stdlib files?)
Do you see any messages if you start IDLE in a terminal?

Terry,

Here is a video I made showing the problem I’m having. I have no clue about the other things you are asking about.

https://www.youtube.com/watch?v=BpyMhdjTNvQ <https://www.youtube.com/watch?v=BpyMhdjTNvQ>

Bruce

> On Jul 5, 2018, at 3:21 PM, Terry J. Reedy <report@bugs.python.org> wrote:
> 
> 
> Change by Terry J. Reedy <tjreedy@udel.edu>:
> 
> 
> ----------
> stage:  -> test needed
> title: Scrolling in IDLE for OS X is not working correctly when reaching end of file -> IDLE: on macOS, scroll slider 'sticks' at bottom of file
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue34047>
> _______________________________________

Confirmed on latest master on OSX.

I'm also experiencing many other kinds of erratic scrolling behavior:
1. Dragging the scrollbar isn't possible immediately after opening the file Lib/idlelib/editor.py.  Also later after scrolling to the top.
2. Scrolling via two-finger swipte on the trackpad scrolls down both when I scroll up and down.
3. Clicking in the trough slightly below the slider has no effect.

There's definitely something very broken!

Commenting out the `return 'break'` in handle_yview() doesn't appear to affect this.

In all cases I ran idle from a terminal via `python -m idlelib` and saw no errors.

With Python 3.6.5 on OSX, I'm seeing all of the issues (including the originally reported one) except the issue with the scroll direction inversion on two-finger swipe.

On OSX with Python 3.7.0 behavior is the same as current master.

We need to determine whether the problem is with tk/tkinter or specifically with IDLE, and whether it has anything with using ttk.  The attached file duplicates the skeleton of an IDLE editor in 14 lines of tkinter code.  This includes putting a ttk scrollbar on the tk frame.  It works for me on Windows.  If it misbehaves on Mac, uncomment ', Scrollbar' on the ttk line to get a ttk scrollbar on a ttk frame.  Also comment out the entire ttk line to get a tk scrollbar on a tk frame.

The mouse over scrollbar behavior I described above is specific to the ttk version.  Mark Roseman has said that other ttk widgets *look* better on a ttk frame. Does the frame make any difference for scrollbar?

Terry, with your minimal scrolling frame with text, everything works fine for me on OSX, regardless of whether the frame/scrollbar are tk/ttk, including using the ttk scrollbar on a tk frame.

So this does seem to be an issue with IDLE.

The text widget in IDLE is actually an instance of MulticallCreator(Text).  For tk_scroll2.py, I added the idlelib import and the call to MulticallCreator.

I can reproduce this problem only with Tk 8.6.7, both compiled by myself or installed from ActiveState (Python 3.7 and 3.6 compiled by myself, too). I can't see it with Tk 8.6.8 provided with the installers, nor with Tk 8.5.18.

With Python 3.7.0 installed from python.org, I can't see any of the scrolling issues with tk_scroll2.py either.

The reported scrolling issues do happen for me with the Python 3.7.0 installed from python.org, which does use Tk 8.6.8.

I've encountered this problem as well.  It occurs with files bigger than a screenful (i.e. use OpenModule to open the collections module).  Both the scroll-up and scroll-down inputs result in scrolling down.  This occurs with a fresh MacOs install of Python 3.7 from python.org.  I do not have the issue on other versions of Python.


    Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 26 2018, 23:26:24) 
    [Clang 6.0 (clang-600.0.57)] on darwin

This is running on MacOS High Sierra 10.13.5 running on a Haswell CPU with Iris Pro.

Re-reading, I notice this from Tal: "With Python 3.6.5 on OSX, I'm seeing all of the issues ...".  3.6.5 was released 2018 March 28, *before* we revised editor scrolling in May.  What tk version?  Was the new 8.6 compile even available for that?

3.7.0 on 10.13.6: Vertical cursor sticks at both ends.  Sticking at the top also is Tal's observation 1 above.  I also verified dead zone under slider and always down with 2-finger swipe, and that this is not normal Mac behavior.

Not able to reproduce this issue using a recent build of Tk 8.6.8 plus (it's been a little while since I pulled the latest updates from core-8-6-branch, but is recent enough). Similar behavior was reported on Tk a couple of years ago but has been fixed; I closed https://core.tcl.tk/tk/tktview/1875c1f30f2d17230a3d6e8fc7c85d244e80b922 to indicate this.

On 10.13.6 with 3.7.0, 'python3 -m idlelib.configdialog' in bash terminal runs configdialog unittests and brings up a human-verified test (htest) driver box with a ttk scrollbar whose slider does not stick.  I has a dead zone beneath or above, but I wonder if this has anything to do with the portion of the file already visible.

Kevin, tk_scroll(2).py are failed attempts at simplified reproducers.  Now that I have a Mac running, I will try again.

Moving the scrollwheel in either direction scrolls down, so I have to use the scrollbar once stuck on the bottom of the file.  (The Macbook has no PageUp key.)  For me, this is the most obnoxious bug.  Tomorrow, I will add prints to the scroll event handling code to see what is being generated.

Having 3.6.5 and 3.7.0 with Tcl/Tk 8.6.8, try to File->Open Module and open ssl module. On 3.6 everything is fine, on 3.7 the scroller sticks at the bottom. A Tk text widget with the same amount of lines shows no problem. Apple macOS 17.7.0 with 64 bit Python and Tcl/Tk. IDLE problem probably.

The solution was very simple on my Mac. In /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/idlelib/editor.py, lines 461-462 should be:

up = {EventType.MouseWheel: (event.delta >= 0) == darwin,
      EventType.Button: event.num == 4}

instead of:
up = {EventType.MouseWheel: event.delta >= 0 == darwin,
      EventType.Button: event.num == 4}

Does this solve the scrollbar locked down issue for anyone else?

Yes! Vlad's fix resolves the "sticks at bottom of file" bug for me on macOS.  It also resolves #2 in my list of additional bugs, regarding scrolling direction.

With both 3.7.0 and current master, I still see additional bugs #1 and #3, i.e. issues dragging the scrollbar slider when it is at the top of the scrollbar and clicking slightly under the slider having no effect.  I'll open a separate issue about that as it seems like something separate.

With:

up = {EventType.MouseWheel: (event.delta >= 0) == darwin,
      EventType.Button: (event.num == 4)}

in editor.py at 461-462 I don't see bugs #1 neither #3 on 3.7.0 but I'll try with other files.

In fact, if the first click before dragging takes place in the upper half of the scrollbar slider, the click is not received nor the drag after. Is like the scroll slider is translated down with half of the slider length (that's why I can drag the slider even when I'm a little bit lower with the pointer). I'll check the click callback and the scrollbar setup functions. Can anybody check if clicking then starting to drag the slider in the inferior half of the slider, even at the top of a file, functions well?

Check the commands below and the results to see why the problem with the mouse wheel appeared:

>>> a = 1
>>> a >= 0 == True
False
>>> (a >= 0) == True
True
>>> a >= (0 == True)
True
>>> a >= 0 == False
True
>>> (a >= 0) == False
False
>>> a >= (0 == False)
True
>>> (a >= 0) == True
True

I've tried to check the source code of IDLE in search of chained comparisons without parenthesis (like the example I showed and the bug with the mouse wheel). I couldn't find something important.

Then I wrote in a file the following code:

import tkinter

root = tkinter.Tk()

text = tkinter.Text(root)
vbar = tkinter.Scrollbar(root)

vbar.pack(side=tkinter.RIGHT, fill=tkinter.Y)
text.pack(side=tkinter.LEFT, fill=tkinter.BOTH)

text.config(yscrollcommand=vbar.set)
vbar.config(command=text.yview)

lines = ['This is the line number %d.\n' % i for i in range(200)]
text.insert(tkinter.END, ''.join(lines))

In both Python 3.6 and 3.7 with Tk 8.6.8 on macOS 10.13, click-and-drag on the upper half of the scrollbar slider has no effect (the slider sticks at the top), like in the bugs #1 and #3. I strongly suspect a tkinter problem, as the equivalent Tcl/Tk code functions well. Click-and-drag in the lower half of the slider functions (in my code and IDLE) for me. Can someone reproduce this?

Edit:

The code is:

import tkinter

root = tkinter.Tk()

text = tkinter.Text(root)
vbar = tkinter.Scrollbar(root)

vbar.pack(side=tkinter.RIGHT, fill=tkinter.Y)
text.pack(side=tkinter.LEFT, fill=tkinter.BOTH, expand=1)

text.config(yscrollcommand=vbar.set)
vbar.config(command=text.yview)

lines = ['This is the line number %d.\n' % i for i in range(256)]
text.insert(tkinter.END, ''.join(lines))
 
def click_trace(event):
    text.insert('%d.%d' % (1, 0), 'Clicked at (%d,%d) on %s.\n' % (event.x, event.y, vbar.identify(event.x, event.y)))

vbar.bind('<Button-1>', click_trace)

root.mainloop()

Clicking at the top on the slider shows that the Scrollbar considers it as being on "through1" (in Tk the zone between the upper arrow and the "slider") and NOT on the "slider". Please, play with the script (python3 tktest.py) and see the results for yourselves.

And the result (video) of my script is attached to this post.

Vlad, can you test the current patch on PR 8678 on Mac?

New changeset 077059e0f086cf8c8b7fb9d1f053e38ddc743f59 by Tal Einat in branch 'master':
bpo-34047: IDLE: fix mousewheel scrolling direction on macOS (GH-8678)
https://github.com/python/cpython/commit/077059e0f086cf8c8b7fb9d1f053e38ddc743f59

The scroll works. Many thanks, I thought the callback should have been rewritten, too. Should one open a different report for the clicks on the scrollbar ends, like in the script I put (independent of IDLE)?

New changeset ea8835fb302447da82f265a5bc0f785353100271 by Miss Islington (bot) in branch '3.7':
bpo-34047: IDLE: fix mousewheel scrolling direction on macOS (GH-8678)
https://github.com/python/cpython/commit/ea8835fb302447da82f265a5bc0f785353100271

New changeset ca4badb5c0bedaa4ebcb33b9cad5f64750876750 by Miss Islington (bot) in branch '3.6':
bpo-34047: IDLE: fix mousewheel scrolling direction on macOS (GH-8678)
https://github.com/python/cpython/commit/ca4badb5c0bedaa4ebcb33b9cad5f64750876750

> Should one open a different report for the clicks on the scrollbar ends, like in the script I put (independent of IDLE)?

Indeed.  Please open a new issue with an appropriate title and attach your example script and video.

I opened #34796 for the scrollbar slider issues.