Scroll Jumping Issue

[F.S.]

Here are some of the details of the scroll jumping issue I noticed. It very reliably occurs on a large file node of mine. The workbook was until days ago edited using 4.7 and I just switched to 4.10 and now 4.11. I have multiple @file nodes in the workbook and I only see this happening on a very large file, but it does not happen on all the sub nodes:

The @file node itself 90 lines, no jumping.

Sub node 1, total 509 lines, no jumping. It also contains a 73 line child node (cloned), which has no jumping.

Sub node 2, total 852 lines, jumps: whenever lines beyond line 844 is displayed, a mouse click will cause scroll jump so that line 844 is the last line displayed.

Sub node 3, total 1230 lines, no jumping.

Sub node 4, total 1331 lines, always jump to 1305 as the last line displayed, behaving similarly to sub node 2.

Sub node 5, total 1191 line, normal

Sub node 6, jumps 1248 -> 1191

Sub node 7, 1189, normal

Sub node 8, 403 -> 398

Interesting, it seems to only jump on even numbered sub nodes. When it happens, it doesn't matter where one clicks in the edit pane, it always re-scroll to the same place, as if it got the total number of lines wrong for that pane. However the cursor is at the right place, just out of view. One can scroll to bring it back in view, and can enter text normally. A click would push it out of view again.

I am running:

Leo 4.11 devel, build 5418, 2012-07-04 02:53:55 -0500

Python 2.7.3, qt version 4.8.2

Windows 6, 1, 7601, 2, Service Pack 1

Hope this helps!

[F.S.]

Now sub node 8 has grown to over 422 lines and it now always jumps to line 422 as the last line. The increment with the last jump threshold is 24 lines. Not sure what is magic about 24? My edit panel is sized to display 20 lines. Resizing it to display more or less does not affect the last line displayed.

[Terry Brown]

On Tue, 17 Jul 2012 10:49:11 -0700 (PDT)
"F.S." <speec...@gmail.com> wrote:

> Now sub node 8 has grown to over 422 lines and it now always jumps to line
> 422 as the last line. The increment with the last jump threshold is 24
> lines. Not sure what is magic about 24? My edit panel is sized to display
> 20 lines. Resizing it to display more or less does not affect the last line
> displayed.

I looked for any suspicious hardcoded 24s or 23s but didn't see any.

Hopefully Edward will have time to look at this soon. He's more
familiar with the relevant code than anyone else - I'd get to it
eventually, but yesterday's Leo file diffing tool was my Leo time for
this week.

Cheers -Terry

[F.S.]

I have done some more work to try to isolate the jump problem:

I have created an outline with a single node. The node contains 146 lines. When one clicks anywhere at the end of the node it will always jump to line 145 as the last line shown (probably really line 144 since line 145 is slightly hidden at the bottom). One can add a few lines after line 144 without affecting the behavior.

Before line 144 there are 858 characters. It doesn't  matter what they are, but there must be at least 858 and must be before line 144. One can move the text around so long as these conditions are met the jump reliably happens. If one remove text so that there are fewer letters left, the jump go away.

It doesn't matter where the node appears the above holds true.

I have uploaded the file as an attachment to this post.

I am using:

Leo Log Window

Leo 4.11 devel, build 5418, 2012-07-04 02:53:55 -0500

Python 2.7.3, qt version 4.8.2

Windows 6, 1, 7601, 2, Service Pack 1

I don't use any private leoSettings. Body panel displays about 20 lines as default. I just noticed that the attached outline only display the jumping problem when the window is maximized. I believe that is because some of the long lines start folding back when I use the non max size. After I play around a bit to even out the longest lines I get the exactly same behavior as above whether my Leo window is maximized or not. 

 

I tried to look through the Leo code. I don't have enough high level understanding to locate where this could originate from. It is clear that line count and character count are both somehow involved. However the node position is not relevant. So my previous perception of a pattern there was probably just me being fooled by randomness.

On Tuesday, July 17, 2012 11:09:21 AM UTC-7, Terry wrote:

On Tue, 17 Jul 2012 10:49:11 -0700 (PDT)

"F.S." wrote: