Apache OpenOffice (AOO) Bugzilla – Issue 25483
Unpredictable vertical scroll jumps when drag and drop of selected text exceeds top or bottom edge of document contents area
Last modified: 2017-05-20 10:45:15 UTC
I have found this problem in every version of Openoffice that I have tried, not just the version selected above, which is the latest I am using. I hate using a mouse, and like to use arrow keys to move up and down when reading documents. Unfortunately at page breaks and paragraph breaks instead of smoothly continuing across the break the text suddenly jumps so that the eye has to search for the line that was last being read. This is utterly disconcerting to me, and wastes a huge amount of time when I am reading a document. To observe this simply read in any openoffice or word text file then click on some text to locate the text cursor, and then press the down arrow key. Watch the text jump as the cursor passes a paragraph or page boundary. See if you can read anything like that. The same happens with the up arrow key. Contrast the nice line-at-a-time vertical scrolling if you use the mouse to click on the arrows at top and bottom of scroll bar. I presume this jumpting behaviour was put in because someone did not like to see a small part of the next paragraph or next page as the cursor moves down (or up) the page. And I suppose some people never notice it because they do everything with a mouse and you don't get the problem if using the mouse and scroll-bar. If this discontinuous keyboard-driven vertical motion really is the preferred behaviour of the majority of non-mouse users, please can it be made switchable for people who hate it? I.e. if you pres UP or DOWN arrow you should be able to get the same behaviour as is already provided by clicking on the arrow at top or bottom of the scroll bar. My hunch is that most people would prefer that to be the default for arrow keys also, but even if I am wrong, at least people who want it should have it as an option. many thanks. Aaron == Aaron Sloman www.cs.bham.ac.uk/~axs
set issuetype to enhancement because this ist not realy a bug set OS to all reassigned to the owner of enhancement bugs set default target
Though I can see that this is an important issue for some users, I think that the way to solve it is the implement a Normal Mode for proof-reading rather than spending developers' time on adding an option to change this behaviour. When scrolling from the bottom of one page to the top of the next in page layout mode, where there is a gap to show the page break, the page is going to have to jump by several lines, espcially if there are footnotes at the bottom of the previous page, and a header at the top of the next page.
Comment to Pesala's comment: This is what i thought at first, but if you open a file and try to scroll with the arrows you will see that it's not at the bottom of the PAGE that it jumps, but at the bottom of the SCREEN. Normal mode is ALSO necessary to make the cursor more directly under the control of the arrow keys but not sufficient.
Issue 5401 is a duplicate - but I don't know how to actually mark it as a duplicate, so please can somebody else do it! ;-)
Hi Mathias, I have changed the current owner to your owner. Please take the ownership of these enhancements.
Anything new?
I am a professional writer with several books to my name under major imprints. Have also written for major tech publications and many of the top tech vendors. I use OpenOffice exclusively, and I know other professional writers who have or are making the switch. OpenOffice is that good. However, I have to say this "page leaping" problem is the single most annoying habit of the program. It's also a productivity impediment. When editing large documents, it's nearly impossible to manage formatting and keep your context. The human brain gets confused when the page leaps up, and the text your were working on suddenly disappears. It wouldn't be so bad if the page lept up or down consistently and logically, but it doesn't. You lose the insertion point. It's a mess. As a former developer, I can say with confidence there is no technical reason why page scrolling should not +always+ be smooth, regardless of the application's "mode." This is a bug, not a feature. Competitively speaking, every other text editor and word processor on the market today is capable of moving text up or down one line at a time, including when crossing page breaks. This is a bug that should be fixed, and could be fixed with a few minutes attention.
I completely agree with rblevin that this is a serious bug. Fortunately it does not bother me much because I hardly ever use OO, except to read things sent to me, and I immediately convert to PDF and read using xpdf which does not have this problem. For producing my own documents I use latex. I did recently have to convert a latex document to word because of restrictions of an incompetent publisher, and once again found this jumping behaviour when using the 'up' or 'down' arrow key very annoying i.e. whenever the text cursor hits the top or bottom of the window the next keypress causes the text to jump several lines, losing the visual context. I can't imagine who ever wanted that sort of behaviour. Fortunately I found that using the scroll wheel on the mouse did not produce that behaviour, and that is much less tiring (and rsi-inducing?) than constantly clicking on the arrows at top or bottom of scroll bar which also avoids the jumping. But I would prefer not to have to touch the mouse to get sensible text-scrolling behaviour. I feel very sorry for people who can't use other text processing systems instead of OO. (I have no idea whether this is also in MSword: I have never used that, as I use only linux and unix.) Since there are already two mechanisms that produce the right behaviour it should be trivial to fix the bug. perhaps users who want the jumping behaviour shuld be able to turn it on (are there any??). Or at least enable other users to turn it off. Aaron (Using OO 2.3.1 on Linux+PC)
axs makes an intersting observation that proves this is a bug: >>> Fortunately I found that >>> using the scroll wheel >>> on the mouse did not >>> produce that behaviour The scrolling behavior can and should be the same, regardless of the input device. Simply use the mouse-wheel code with the keyboard, or eliminate this duality altogether by consolidating the scrolling routine.
In addition to be "smooth", auto-scroll should have speed depending on mouse vertical bias from document (thus allows slow and fast scrolling). Also please assign target milestone for this issue.
I changed the target to "3.x" to get it into the quarterly review process.
I have registered just to vote for this. I'm unable to migrate to OpenOffice until this issue is resolved. It's really a deal breaker for me (and also for all of my work colleagues). We do a lot of typing and almost never use the mouse. Proper keyboard scrolling is a must for our type of work. Regards.
I agree that this is annoying. Also, I'm not entirely sure this is the same or a related phenomenon. But when reading through a large text, the mouse navigation also has annoying effects. If I click at the top or bottom line in my screen, and that line does not coincide with the top or bottom of a page, instead of moving the cursor to that line, the text is scrolled to display part of the previous or subsequent text (as described in the original post, I think). This is hugely annoying if all you wanted to do was double-click a word in the top or bottom line of your screen to select it. Instead of selecting that word, the text gets scrolled, and an entirely different word gets selected. As I said, I'm not entirely sure this is the same phenomenon. Hard to describe these effects in text - easier just to show someone IRL.
Ditto this problem. But I see it using a mouse. When scrolling with the wheel mouse or holding the scroll bar, the view will sometimes jump back to the page you were typing on rather than stay on the new page you were trying to view. You have to quick click in the text frame to secure the page view. It seems to happen after typing in one section for awhile. If you load a document and start scrolling through, you don't seem to get this behavior. (WinXP Pro, SP2, w/ most updates, default page view)
May I ask if the original issue - use arrow keys to move up and down through documents causes disconcerting jumps - will ever be addressed?
@All: what about checking "Tools - Options - OpenOffice.org Writer/OpenOffice.org Writer/Web - View - Smooth scroll"?
@es: Nope, regrettably enabling smooth scrolling has nothing to do with the problem. It's the way a document scrolls a number of lines at a time, rather than one, when navigating it using the up and down arrow keys that's infuriating. Not only is it illogical, it's also difficult to focus on the line that you need to be looking at when things are jumping around!
martyn01 wrote: "enabling smooth scrolling has nothing to do with the problem." right! "It's the way a document scrolls a number of lines at a time, rather than one, when navigating it using the up and down arrow keys that's infuriating." Yes. To be more precise: there are configurations where pressing up or down arrow key does not behave like mouse clicking at top or bottom of scroll bar (which behaves correctly) but instead using the arrow key moves the text and mouse cursor a much larger, unpredictable amount, requiring visual search to sort out what has happened. I suspect that at some distant past time a clever programmer with little understanding of human interface issues thought that would be a useful facility and went to some trouble to insert it, without making it an option that can be turned off. I can't see any reason for breaking the tight correspondence between the good behaviour produced by using mouse at top or bottom of scroll bar, and using Up and Down arrow keys. (Probably most users use mouse only and so never complain about this behaviour.) There should always be a keyboard-only alternative to something that can be done with the mouse. I suspect that in this case restoring the correspondence should be trivial (replacing one function call by another that is already in use, namely move text cursor up or down one line, and if necessary bring the new line (and NOTHING MORE) onto the screen. If the text pointer moves onto a footnote just bring that line up anyway -- don't try to be clever and jump over the footnote (as suggested by Pesala in 2006!). If the new line is blank, just show the new blank line, and let the user decide what to do next. Providing an option that prevents scrolling off one page onto another as some PDF viewers do is another matter. Then moving to the next or previous page would be a different action (e.g. PageUp or PageDown). But for 'continuous' scrolling, don't insert discontinuities. This is not revolutionary stuff: it's what OO does with mouse and scroll wheel actions anyway, and every other text editor I have used also does. So, let's please have it with arrow keys also. Thanks. Not only is it illogical, it's also difficult to focus on the line that you need to be looking at when things are jumping around!
The issue type should really be a BUG, not an enhancement. For god's sake, Writer is a word processor therefore one would expect to be able to work with such an application using keyboard only, or at least without the need to reach for a mouse in order to scroll text line by line. Regards.
*** Issue 124031 has been marked as a duplicate of this issue. ***
Please see some detailed comments at <https://issues.apache.org/ooo/show_bug.cgi?id=124031#c1> Might have been an enhancement 2000, but for 2014 software it's a bug.
But not a major one, cut/past is not unreasonable.
Reset the assignee to the default "issues@openoffice.apache.org".