NOT reproducible with "LibreOffice 3.5.1.1 German UI/Locale [Build-ID: 45a2874-aa8c38d-dff3b9c-def3dbd-62463c8] on German WIN7 Home Premium (64bit).

Linux related?

@reporter:
Thank you for your report – unfortunately important information is missing.
May be hints on <http://wiki.documentfoundation.org/BugReport> will help you to find out what information will be useful to reproduce your problem? If you believe that that  is really sophisticated please as for Help on a user mailing list
Please:
- Attach a sample document (500 pages lorem ipsum or similar, 
  not only screenshot)
- Attach screenshots with comments if you believe that that might explain the 
  problem better than a text comment. Best way is to insert your screenshots
  into a DRAW document and to add comments that explain what you want to show
- Contribute a step by step instruction containing every key press and every 
  mouse click how to reproduce your problem (due to example in Bug 43431)
– if possible contribute an instruction how to create a sample document 
  from the scratch
- add information 
   -- concerning your PC 
  -- concerning your OS (Version, Distribution, Language)
  -- concerning your LibO version and localization (UI language, Locale setting)
  –- Libo settings that might be related to your problems 
    (video hardware acceleration, soft scroll, ...)
  -- how you launch LibO and how you opened the sample document
  -- everything else crossing your mind after you read linked texts

Even  if you can not provide all demanded information, every little new information might bring the breakthrough.

bug is still there in libreoffice version 4.0.3.3  (Build ID: 0eaa50a932c8f2199a615e1eb30f7ac74279539)
under windows xp professional with service pack 3

I don't see what "important information" is missing in the description provided in the original post:

"When scrolling up or down through a multiple page document with up-arrow key 
or down-arrow key. The screen display jumps by multiple lines - approximately 
1/3 of the document window-height on an 1600x1200 display - when the cursor 
reaches either the top or bottom edge of the document display. So, for example 
when you reach the bottom of the screen the screen will jump up by e.g. 10 
lines bringing the cursor up by these 10 lines. Then the cursor travels down 
to the bottom causing the screen to jump up again. So your gaze has to jump up 
something like every 2 seconds if you want to keep an eye on the cursor."

And I agree completely with the original poster: "This makes LibreOffice Writer 100% unusable. (I mean that. Unusable.)"

Created attachment 80644 [details]
shows how libreoffice writer differs from microsoft word when scrolling down

The attachment shows on pages 1 and 2 screenshots of what happens in LibreOffice writer when you scroll down your document, the cursor arrives at the bottom of the document window and you hit the down arrow one more time.
--> the document text moves up by e.g. m=10 lines and the cursor moves up with it by n=m-1 lines, i.e. in this example by 9 lines

In all other word processing programs and text editors that I have ever used (with the exception of Apache OpenOffice writer and Calligra Words) the behavior is different (and MUCH better).

Example: See pages 3 and 4 of the attached file (Microsoft Word 2010)
When cursor reaches the bottom of the document window and you hit the down arrow key one more time the document text moves up by just one line while the cursor stays at the bottom of the document window.

I have experienced this undesired scrolling-behaviour in every version of OpenOffice/LibreOffice from version 2.x until the current version 4.0.3 under different Linux distributions (OpenSuse, Debian and Ubuntu) and under Windows XP and Windows 8.

I therefore can't understand why Rainer could not reproduce it.

Created attachment 92627 [details]
Testdocument for view jumping when cursor comes to the bottom or top of screen

View jumps 8 lines when cursor comes to the first or last line that is visible on LO Writer screen. Tested with LO 4.2.0.2 on Ubuntu and Windows.

I think it's a feature so that you don't have to go to every single line. The feature is only annoying if you're scrolling through the whole document or more than some lines.

Confirmed. Marking as:

New
Enhancement - the product works as designed, reporter wants it to behave differently.


Please remember that LibreOffice (and The Document Foundation) has no power as to when or if enhancements get implemented. A volunteer developer would have to accept doing the work. Thanks for the suggestion.

Appreciation to all who work on LibreOffice.  I'm glad I donate. 

Yes screen jumps up and down 8 lines in Writer in every version of Open Office and Libre Office I've tried.  I just uninstalled and reinstalled LibreOffice Still.  Now it's jumping again. 

Happens when document is just sitting displayed and live, without me touching anything.  

Has happened to me repeatedly-intermittently on both PC and Mac systems since 2001. 

Happens primarily on documents over 50 pages. 

Therefore pretty major--but may be a formatting issue.  See below. 

My investigation suggests screen jumping in writer is highly connected to old formatting when old Word 2003 and 2008 are brought into LibreOffice.

I've published 20 books, updating them often.  So the bug may be to determine what old formatting from earlier OO and Libreoffice docs is "indigestible" in later versions.  

The vertical jumping I think is the system trying to respond to one or more of these formatting from earlier word processing software:

- headers-footer 
- table of contents
- artifacts from old Heading 1 and Heading 2 formats

Even with this awareness, and stripping old docs back to text only and big use of "Clear formatting", I cannot guarantee screen jumping won't come back.  

So I am frustrated like the other posters.  The skeptics of this bug are apparently ignoring the parameter of LONGER DOCUMENTS.  I can't recall this bug on documents, under 50 pages.

To add some evidence for debugging:

1) I wrote my thesis entirely in Libre Office 4.1.3.2. Thus, the cause is unrelated to importation of earlier word documents, only a coincidence.

2) When I would open it the scroll behavior was as desired, single line scrolling after cursor reached bottom of screen. It was only after a few minutes when it started 'jumping' ~ 15 lines at at time.

3) Saving, closing, and re-opening did not alleviate issue.

4) page count is 99.

A temporary solution:

On the standard tool-bar de-select 'edit-file' toggle button (has the same icon as 'Styles and Formatting (F11)' button)


Some discussion:

Has anyone authoritative (By this I mean has read and understood the code controlling this behavior) commented on if this is as designed (referring to the comment  - “New Enhancement  - the product works as designed”)


Side note:

My girl friend did her thesis entirely in MS Word and it exhibits the same behavior.

It's an assumption based on:

1) Behavior of other office suites being the same;
2) It makes sense that it could be desired that it behave this way as you might want to see multiple lines on top and bottom of your current position.

We can't get absolute confirmation of enhancement requests of every bug (that would be horribly time consuming for over worked developers).

The other point is if this is not an enhancement request then it would qualify as a MINOR bug (slows down professional quality work but does not prevent it) - therefore, if you feel more comfortable with it being marked as a bug, please mark it as MINOR - LOW.

Thanks for the kind words about our contributors :) We all try to work very hard to make it better for everyone

I can conform that this happens in version: 4.4.1.2 build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 on Windows Vista with all updates. And I don't really like it - it means that the text makes jumps and when you have many headings in the text (involving different line heights), it's not easy to track the cursor. 

I don't believe in "MS Word has this, so why don't you?" because the solution in MS Word might just be plain bad. But in this case, I suppose, MS Word has it because it's better than the behavior in Libre (and in Apache OO as well, btw). It's easier on your eyes, for instance, when you do a lot of scrolling by arrow keys.

Absolutely agree with this bug/feature. 

I think this is bug because any standard text editors (MS word, PSPad, Ultraedit, PHPEd etc.) dont implement this "shaky" behavior. 

Standard: When I move cursor one line “over” the top/bottom page. The page scroll just one line so I easy know where Im.

Open/LibreOffice: The page SKIP let say about 10 lines. It is extremely annoying to find where the cursor is and orientate the page.

Im using Win7, LibreOffice 4.4.1.2

Please don't change/manipulate the priorities. Priorities have objective definitions and this is not in any way a major bug. Please don't do it again.

I personally prefer the current behavior. The only time I scroll line by line is when I am typing the text in. The text moving too often (after every line) is a distraction.

As for just scrolling using arrows (why do that is beyond me), I wouldn't care, Page up/down keys are there for me. And apparently nobody has been annoyed enough to write a patch.

*** Bug 101020 has been marked as a duplicate of this bug. ***

Since I thought duplicate bug 101020 could use UX input, I'm adding the keyword here.

There are clearly pros versus cons, you either keep the current line focused or loose the ability to read whole paragraphs. 

An alternative solution could be to introduce "smooth scrolling", as known from Mozilla Firefox, and scroll slowly up the 8 lines. Doing so supports the physiological capabilities of eye movements. On the other hand there is not much to say against an option how many lines to scroll per arrow.

(There is an _expert_ option ooO.Writer/WriterWeb > Layout > Window > SmoothScroll that defaults to false, but I don't see any effect when changing it)

(Removing needsUX but CC'ing the mailing list)

I strongly agree with this complaint. 

User interface behaviour should be consistent, and the effect of down arrow is INconsistent depending where your cursor is located on the screen. It goes down one line, one line, one line, then suddenly jumps 10 lines because you're at the bottom of the screen. Totally disorienting.

Please make this an option people can turn off if they want to.

If I want to jump large distances in the page, I'll use Page Up/Down or take my hands off the keyboard and use the mouse.

Any news about this? 

If the described behavior (ie "jumping" several lines) is intended I think somebody should defend it. I mean somebody should say "it is intended due to such and such reason and that is why this behavior is desirable in this application" and not "I don't mind using it like this".

If the behavior is not well justified I think the "jumping" behavior makes LibreOffice Writer look kind of sloppy...

I'm with J22Gim@gmail.com on this one.

(In reply to J22Gim from comment #22)
> Any news about this? 
> 
> If the described behavior (ie "jumping" several lines) is intended I think
> somebody should defend it. I mean somebody should say "it is intended due to
> such and such reason and that is why this behavior is desirable in this
> application" and not "I don't mind using it like this".
> 
> If the behavior is not well justified I think the "jumping" behavior makes
> LibreOffice Writer look kind of sloppy...

LibreOffice Writer already supports a Smooth Scroll [1], that is disabled by default. It does not completely remedy this, but it mostly functions (I've noticed some canvas "tearing" while scrolling when OpenGL is enabled).

So it is enabled from a Writer session. Tools -> Options -> LO Writer -> View: Smooth scroll check box.  Then restart LibreOffice. 

The long present feature works by building additional views of the document and swapping them to VCL canvas sequentially during scroll--as opposed to the single view--which would appear to jump.

But, it imposes additional overhead, and was even disabled for macOS builds due to the performance impact. Nor is it used on newer Android and iOS builds.

Some refactoring is probably overdue, at least to restore for OS X builds--and with HA and OpenGL rendering support--seems more could be done.

@Michael M, any thoughts on behavior of this and direction of the RFE? 

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/sw/source/core/view/viewsh.cxx?h=1224#1221

> LibreOffice Writer already supports a Smooth Scroll [1], that is disable
> by default. It does not completely remedy this, but it mostly functions

   Hmm, interesting. Of course - the real optimization with scroll is to accelerate the big copy-area which happens when we scroll down I guess, and to ensure we render only the 'new' content.

   Writer is however doing a ton of dumb stuff with OpenGL turned on, including rendering to off-screen drawables and consuming lots of memory:

> But, it imposes additional overhead, and was even disabled for macOS builds
> due to the performance impact. Nor is it used on newer Android and iOS builds.

    Both Android & iOS do tiled rendering separately anyway; so it shouldn't be used there.

> @Michael M, any thoughts on behavior of this and direction of the RFE? 

    I would be surprised if this particular piece of code did much good, and I'd prefer to have faster, simpler code-paths there. Rendering and/or moving a screen-full of pixels on the GPU should be so close to instant that there is really no problem - so there must be some other silly here: perhaps key-event handling priority vs. rendering, vs. typematic rate affecting how many events we get queued, and ... that sort of thing I suspect =)

    The solution is just some engineering to timestamp the events, and time the re-rendering sections, and do the fixing that becomes obvious from that I'd imagine.

*** Bug 114835 has been marked as a duplicate of this bug. ***

(In reply to V Stuart Foote from comment #24)

> 
> LibreOffice Writer already supports a Smooth Scroll [1], that is disabled by
> default. It does not completely remedy this, but it mostly functions (I've
> noticed some canvas "tearing" while scrolling when OpenGL is enabled).
> =-ref-=
> [1]
> https://opengrok.libreoffice.org/xref/core/sw/source/core/view/viewsh.
> cxx?h=1224#1221

Maybe the code you're referring to supports Smooth Scroll, but I can tell you that in practice it does not work. I tried several times switching back and forth with and without "Smooth scroll" and with and without restarting, nothing happens. I never actually worked in my previous versions of LO as far as I remember. I filed a bug but it was (erroneously?) marked as duplicate of this thread....
Version: 5.4.4.2
Build ID: 1:5.4.4~rc2-0ubuntu0.14.04.1~lo1.1
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group

*** Bug 114835 has been marked as a duplicate of this bug. ***

The "smooth scroll" option is still present in Version: 6.0.1.1
It does nothing.

¿Why keep offering an option which has no effect whatsoever? I find it weird. 
Considering that the 1st message of this thread is from 2012, wouldn't it be more elegant to at least *remove the option* until something can be done about it? It just seems it is not a priority for LO developers (and I'm not in a position to question that), so why not simply remove the option and (likely) forget about this? In this case, I don't agree with "let's leave it until we fix the real problem in the code", because it seems a little strange to maintain several versions of the same application keeping an option without any effect (and of course, even more considering that this is known for so long).

Just my thoughts.

Version: 6.0.1.1
Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4; 
Locale: en-US (en_US.UTF-8); Calc: group

For what it's worth, as a longtime Office user, I thought I'd try switching to LibreOffice in preparation for an eventual move to Linux (currently on Windows 10).

As others have described, the way it suddenly jumps 10 lines when you navigate the cursor past the bottom of the page is extremely disorienting (and the "Smooth Scroll" option seems to have no effect).  As it is right now, I really find it to be pretty unusable :/ Fingers crossed that this gets addressed before I actually do need to move to Linux.

I confirm the bug/feature.

May I also add that by default GNU Emacs behaves in a similar way.
It also has variables scroll-step, scroll-conservatively and scroll-aggressively, which control this behaviour.

...Is perhaps a some more appropriate place to bring this up for discussion?  Seven years & counting (and it seems, no attention/consideration/replies in well over a year)?

A code pointer: SwView::GetYScroll(). Making it return 1 instead of (m_aVisArea.GetHeight() * nScrollY) / 100 would provide almost what is needed. Whoever interested would need to make sure that scroll happens to whole line (instead of "about whole line"); and to implement the user setting for that.

Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.

Still present in Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 60(Build:1)
CPU threads: 24; OS: Linux 6.2; UI render: default; VCL: qt5 (cairo+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 4:7.6.2~rc1-0ubuntu0.22.04.1~lo1
Calc: threaded

*** Bug 99608 has been marked as a duplicate of this bug. ***