reassigned to bh

The problem seems to be more general. Use your mouse wheel or scrollbars to
scroll to a position where the text cursor is not visible any more. 

Additional examples that let the visible section jump back to the text cursor are:

- Press a cursor key (arrow)
- Press a character key
- unselect a graphical element

If you are just proofreading a text and press an arrow key (or if you're doing
anything else that has nothing to do with the cursor position, like saving, as
described by rpeckhoff), this behavior is confusing. 

The same applies to working with graphics. Often I use a magnified view, so the
cursor is out of sight. As soon as you unselect a graphical element using
Escape, the visible section jumps back to the cursor in the text and you have to
search the correct section again.

Word, for instance, acts more intuitively: If you hit an arrow key, the cursor
is set to the lowest or highest line of the currently visible text, depending on
the arrow key you hit (if the arrow down is hit, the cursor is set to the lowest
line, if you hit the arrow up, the cursor is set to the top line). If the
document is saved, nothing is changed. Same for unselecting graphical elements. 

If you continue typing, though, the cursor is not moved and Word moves the
visible text section to the cursor position, which is intuitive again.

It would be worth thinking about different actions in Writer (as saving, hitting
arrow keys etc.) and their most reasonable effect on the cursor and/or the
position of the visible text section. The current situation is not satisfactory
at all.

Thanks,

Simon

*** Issue 64454 has been marked as a duplicate of this issue. ***

This isn't really an enhancement, I consider this a defect.

*** Issue 73288 has been marked as a duplicate of this issue. ***

Adding cc, as getting really frustrated with this. A similar irritation is the
cursor moving to the start of the last index on doing a "tools" > "update" >
"update all", where the view ends up jumping there.

*** Issue 77903 has been marked as a duplicate of this issue. ***

Just a comment to rollom's addition.

> If you are just proofreading a text and press an arrow key (or if you're doing
> anything else that has nothing to do with the cursor position, like saving, as
> described by rpeckhoff), this behavior is confusing. 

Saving shouldn't change the view, right. For the arrow key see below.

> The same applies to working with graphics. Often I use a magnified view, so the
> cursor is out of sight. As soon as you unselect a graphical element using
> Escape, the visible section jumps back to the cursor in the text and you have 
> to search the correct section again.

I tend to agree here. There is no reason to jump to the cursor position.

> Word, for instance, acts more intuitively: If you hit an arrow key, the cursor
> is set to the lowest or highest line of the currently visible text, depending 
> on the arrow key you hit (if the arrow down is hit, the cursor is set to the 
> lowest line, if you hit the arrow up, the cursor is set to the top line). If 
> the document is saved, nothing is changed. Same for unselecting graphical 
> elements. 

I'm not sure if that really is "more intuitively". But OTOH I don't deny it.
Perhaps this is something we should think about. Thanks for pointing this out.

> If you continue typing, though, the cursor is not moved and Word moves the
> visible text section to the cursor position, which is intuitive again.

How is that different to Writer? Maybe I misunderstand what you have written but
to me it looks as the same what Writer does.

> It would be worth thinking about different actions in Writer (as saving, 
> hitting arrow keys etc.) and their most reasonable effect on the cursor and/or 
> the position of the visible text section. The current situation is not 
> satisfactory at all.

Thinking is always a good idea. :-)
Thanks for your comments.

Matthias, would you like to comment on that? 
As Frank already pointed out, changing the view after saving looks like a
defect. I also think that keeping the view when an object is deselected would be
a good enhancement. I'm in doubt about the cursor movements.

>Cursor movements

Hmm... I see your point. But could Word compatibility be a reason for a
decision? If there are no other reasons? 

>How is that different to Writer? Maybe I misunderstand what you have written >but
>to me it looks as the same what Writer does.

You're right, Word does the same here. Guess I just wanted to show the
difference between the two possible behaviors then.

Cheers, R.

Target for fixing the autosave problem is 2.4
I don't want to change something for cursor movement and character input.
I also would like to change the behavior for deselecting objects - it might be
that fixing that is too hard for 2.4, we'll see.

fme: The autosave jump has been fixed with i81697. Therefore I'll change the
target to 3.x.

it is claimed in 2968 that jumping to cursor when saving was fixed... in year 
2003.

fme->richlv: Jump on save has been fixed with issue 2968. Jump on autosave has
been fixed with issue 81697. This issue is about some more (possibly) unwanted
jumps.

This is most frustrating when using Format Paintbrush on normal text.

*** Issue 89006 has been marked as a duplicate of this issue. ***

Issue 89006 is an accurate description of ny comment on Thu Apr 24 18:17:07
+0000 2008.

*** Issue 89261 has been marked as a duplicate of this issue. ***

The same is true when doing a mail merge.

I have the spreadsheet (database) open at the top of the screen.
I have the text document open at the bottom of the screen.

the Writers Guide says to click on the column of the spreadsheet you want to
insert as a database field, and drag it to the text document so it will be
inserted at the point you want it to appear.

But when you do this, the doc jumps all over the place.

Even if you put your cursor into the spot you want to insert, when you drag the
field down, the doc jumps up.

this is driving me crazy!  and forcing me to make mistakes by inserting fields
where they don't belong.

Please change this!

My OS is Windows 2000 SP4
OO ver 2.4.0

I'll be happy to post docs & spreadsheet for testing.  Please let me know
margo.ritaATgmail.com

I just wanted to point out, that this bug is still present in the 3.0 beta, and
it is REALY annoying to read a document, without pressing anything remotely
resembling a key that should focus on the cursor position, and have it jump
around every 30 seconds. (Dunno if that has anything to do with autosave, but
that's the average time between jumps for me).

fme->ramuuns: As I already stated on 2008-04-02, there are a couple of reasons,
why the view might jump to the cursor position. Some of them have already been
fixed. There might be others, which haven't been fixed yet. Please give us some
more information of how to reproduce the behavior you observed. Maybe you can
attach a bugdoc which can help us to nail this down.

I'm not sure, but I think, it happens sometimes, when I use the mousewheel and
only scroll "half" and then back, but I'll take a look too.

Opened: Fri Nov 14 07:56:00 +0000 2003 !!! This issue has been opened for
correction 5 years before, and it's still under 'heavy' discussion. *IF* this is
considered as a 'feature' instead of a vanilla bug, then put it switchable
on/off in the User's Options dialog, but PLEAAASE do something. When I use any
other editor (notepad, wordpad, word, whatever) I'm not relocated at the cursor
position. If I'm currently reviewing the text by scrolling back/forth several
pages away from the cursor position, I just *DO NOT WANT* to be warped all of a
sudden somewhere I've left the place unedited.

I understand some of you just accept this, pretend it's a major 'feature' of OO
from its opponents, but if every other software has chosen the other way, that's
probably because that's the right way to go. It just puts me on my nerves
whenever Writer relocates the view for one reason or another. Imagine you're
looking for a file in the directory tree of the file explorer, and all of a
sudden, you're relocated in another directory you've left 5 minutes ago : *THIS
IS ANNOYING* ! It doesn't kill its man, yet it makes you waste your time !

And no, clicking everywhere to relocate the cursor in the current view ain't the
option I'd like to look for. I'm not yet cursed with Parkinson, time will make
its effect on me at the right moment. So please consider this issue as solvable
(you're the code guru after all) and please do not find excuses such "I cannot
reproduce" or "I like it that way" or "It makes OO unique", whatever, just solve
it !

Full ack., kochise. This most annoying bug has NOW to be fixed. I experience the
problem a dozen times a day as I am writing on a book, and it GOES ON MY NERVES.

fme->kochise/rollom: Please read my comment May 26 21:26:38 +0000 2008.

kochise->fme : just install OO french with or without french dictionnary (which
is a pain to set up working while installing is easy, but that's another story).
Then write a looooooong text (several pages) or just load one. Scroll away from
the cursor andd wait autosave or trigger saving by menu or KB shortcut, the view
jumps.

And no, in IE or Opera, when I leave the cursor in an editable field or have
selected some text, the view ain't scrolled up to the cursor/selection. Either,
a flash ads banner doesn't relocate the view when it refresh its content, just
to make things clear...

This issue last from 2.0.x for me, I never though it was a bug, I always
believed that's another StarOffice legacy from the vi/emacs command-line gurus
behind the project ! I looked hard for a switch, but I'm working on a thesis and
this OO behavior is... well, I'll stay polite to say the least.

fme->kochise: I just tried to reproduce this with a DEV300m10. Nothing happened,
which does not actually surprise me, since we fixed a jump-to-cursor bug on
save/autosave some time ago. Anyway, there might still be an other root cause of
the phenomenon you observed. Please attach a document that shows the described
behavior.

kochise->fme : cannot give you the docs, these are personal datas. Yet keep in 
mind that it happens on large file, usualy when there is a load of pictures and 
the file weight more than 2/3 Mb. Also I'm using stable 2.4.0 right now, 
haven't given 3.b a try... Thanks for taking my inputs into consideration :)

See also that issue and the thread linked (some additional explanation): Issue
61649.

I'll have a look.

In fact, it's probably the very same behavior that happen when a sheet crosses
the  page or screen boundary (a large sheet on which you have zoomed). Select
downward the rows from the beginning of the sheet until you reach the bottom of
the page or screen. Instead to scroll down to allow you to select more rows
(unlike Word/Excel or simply the file explorer when you select several files)
the view jumps upward to the beginning of the sheet, preventing you from
selecting more rows... You have to unzoom enough, what makes things less precise
with a slow redraw due to the quantity of things to display :)

*** Issue 85534 has been marked as a duplicate of this issue. ***

Another confirmation that this is still present in 3.0 beta 1 and in DEV300m23
(Build-9326). I assumed it was autosave, but perhaps not (has anyone tried
turning off autosave to see if the problem goes away?) 

Just now I loaded a "Recent" document, it opened it with the cursor more or less
where it had been when I last saved; then after about half a minute (while I
didn't even have focus in the OOo window) it jumped two or three pages down,
definitely NOT where the cursor had been last time.

Where I see it most often, though, is after saving. It goes like this: finish
typing, hit Ctrl-S. It takes maybe 10-20 seconds to save before the progress bar
disappears. As soon as the progress bar goes away, I use the mousewheel to
scroll down and continue proofreading. I typically get two or three pages down
(maybe half a minute) when suddenly it jumps back to where the cursor is. and I
have to repeat the scrolling down and finding my place. Is there an operation
that typically happens half a minute or a minute after saving which could
possibly cause jumping back to the cursor position?

Hello at all

akkana wrote: I use the mousewheel to scroll down and continue proofreading.

I think, I have the same problem with my mouse, after I used the weel. I don't
know, why it happens, but sometimes after I only scrolled down with the wheel,
the window jumps back, where the cursor is. I'm not sure, if it's a problem with
refrehing the screen and have the cursor outside and used to scroll the wheel.

It seems this could be resolved in 3.0 Beta 2 (Build BEB300_m3)?
Maybe other people can test.
See also http://www.openoffice.org/issues/show_bug.cgi?id=61649

I'm still seeing it in DEV300m23 (Build:9326) which I think is within a few days
of beta 2. I'm also seeing other problems with mousewheel scrolling, e.g.
sometimes the document zooms in or out (when I definitely don't have any
modifier keys pressed).

This bug is still present in 3.0 (open SuSE 11.0).
The view also jumps if I turn Change Tracking on or off.
Scenario: Change tracking is on/off, scroll down, turn off/on tracking, view jumps.

*** Issue 95778 has been marked as a duplicate of this issue. ***

*** Issue 97263 has been marked as a duplicate of this issue. ***

I'd also like this to be resolved, as it is the most annoying bug in writer (in 
my opinion).
"jump to cursor" is done whenever the document gets redrawn (eg changing a 
style will trigger a jump). I also don't know why triggers for this odd 
behaviour have to be found. A jump to cursor should never happen under any 
circumstances except for user input (through the keyboard)!

(OOO300m8 Build 9357)

I'm experiencing this on version 2.4.1. If I have a long doc, put the cursor of
the edge of the screen and press Ctrl + S, to save, it jumps to the cursor
location. 

Pretty annoying, but perhaps not the end of the world.

I just started experiencing (noticing?) this problem in 3.1, and it's pretty irritating. I'm on OS X 10.5.6 and 
was previously using OO.o 3.0. The most annoying instances of this defect:

-save and autosave, like everyone else is mentioning.
-switching windows (maybe Mac specific?). Create 2 multi-page documents. Scroll till the cursor is off 
screen in one document, then switch OO windows to look at the other document. Switch back, and feel the 
frustration as OO loses your place in the first document as it jumps back to the cursor. This is particularly 
annoying when I have one document open to read while I write in the other. If I plan on switching 
documents, I can't just scroll. I have to remember to keep clicking on the page as I read so that the cursor 
keeps up with me.

also having similar problem - it is really annoying - I can't evenly scroll
document with mouse-scroll now. It auto-scrolls back to cursor at random moment
while I scroll the pages with scrollbar or mouse-scroll. :(
note, that I didn't experienced it until OOo 3.1.0m11 ! fix that plox

Oh man it's soo annoying ! Please remove that in next rel !!!!!! OOO 3.1 for 
Windows is the first release for Windows where I experienced that issue, so 
someone who got it in 3.1 should be kicked in balls several times. I use OOO 
always in same way and never experienced that issue before !

I also experienced this with 310m11 Hungarian on Windows XP SP3. When I scroll
with the mouse wheel or the scrollbar, the document randomly jumps back to the
cursor, but it always jumps back 0.5-1s after I started the scrolling.

I have attached 2 text documents with the same content, with the first I
experience the jump to the caret position on save, and not with the second.

Tested with OOo 3.1.0 FR/US on Ubuntu 8.04. 

Created attachment 62831 [details]
text doc with jump to cursor position on save

Created attachment 62832 [details]
text doc without jump to cursor position on save

*** Issue 102535 has been marked as a duplicate of this issue. ***

*** Issue 102347 has been marked as a duplicate of this issue. ***

*** Issue 102580 has been marked as a duplicate of this issue. ***

It appears to be a random issue which is not always reproducible (MRU and I
couldn't on Vista, XP, Ubuntu, MAC...).

But anyway a real issue.
(Has a lot of sub duplicates since 3.1 exists)

Reassigning to a potential "fix-master" for such things. ;)
Setting MBA on CC.

Appears to be quiet a paradoxic issue.

Adding CC

*** Issue 103396 has been marked as a duplicate of this issue. ***

*** Issue 101961 has been marked as a duplicate of this issue. ***

Since 3.1.0 this issue is really annoying. Sometimes Writer jumps many times per
minute, another period there are no jumps. Temporary I thought this issue
occures after long work - more in the evening than in the morging. But this not
always true. It's weird. Do you need screen videos showing the unwanted jumps?
(But what coult they show you except that this issue really exists.)

@lendo: as I said, we (from QA) cannot recreate this issue whatever system we use.
Normally this issue should be closed as WORKSFORME.

But considering the numbers of duplicates we had about this in the last months
(on every systems) I decided to reassign to a developer *without* beeing able to
reproduce it (this is an exception!).

Sum up: Yes, we care! But as long as we don't have an exact scenario to
reproduce it, WE cannot fix it!

If you want to help (and I talk to all other CCs), try to find a scenario where
this is always reproducible.

I mean, I cannot understand why we all here cannot rproduce it on different
systems...

There must be something in the way to install, the programs running in the
background, the extensions installed... I don't know.

So please try to find THE situation which leads to this bug.

If you can reproduce it "only in the evening and while having *sometimes* a blue
carpet on the floor" there is quite no chance that we can fix it...

I think I CCed this issue when I was using a version which had the jump
triggered by the autosaving. I'm using version 3.0 (in Ubuntu 9.04) and I cannot
reproduce the problem with the autosaving. What I did? I positioned the cursor
in a paragraph and inserted some characters in there. Then I used the scroll
wheel to scroll two pages down. Then I waited for the autosaving and it didn't
trigger the jump.

The only situation in which I was able to trigger an "unwanted" jump now is the
following:

- Position the cursor.
- Use the scroll wheel to scroll some pages down or up so that the cursor goes
out of sight.
- Press one of the arrow keys, Home, or End. Bingo! Unwanted jump. 100%
reproducible.

Of course, if one wants the jump or not is debatable. To me this behavior is
somewhat inconsistent with the behavior of the keys PageUp and PageDown. When
you press these keys they (almost) always reposition the cursor to the middle of
the *destination* screen so that you end up seeing the page that you think
you're going to. On the other hand, the other motion keys (the arrows, Home, and
End) reposition the cursor relative to its current position, which triggers an
unwanted jump to the page where the cursor was.

There seems to be lots of alternatives to make all motion keys behave the same:

1) Make PageUp and PageDown behave like the other keys so that they move the
cursor relative to its current position and jump to there.

2) Make PageUp and PageDown simply scroll without moving the cursor. This way
they would feel completely different from the other keys and could be regarded
as different kinds of motion keys, more like the scroll wheel which doesn't move
the cursor at all.

3) Make the other keys behave like PageUp and PageDown, i.e., if the cursor
isn't visible, they should reposition the cursor to the middle of the current
page and move if accordingly.

4) Make the other keys move the cursor relative to its current position but do
not jump to it.

I don't like (1) because it makes for more unwanted jumps.
(2) is better but by itself it doesn't solve the unwanted jumps from the other keys.
(3) would be ok if we had a "back button" to go back to where the cursor was.
But this is another long standing issue (#5608).
(4) doesn't work because then the only way to find out the cursor would be to
insert some character without looking.

I can't see a clear winner. Perhaps there are other possibilities still. If we
had a back button I'd vote for (3) but without one I think the principle of
least surprise would lead me to vote for (2) plus a good explanation of the
behavior in the manual.

As an aside (2) seems to solve yet another problem. As it is, when you PageUp or
PageDown it tries to reposition the cursor to the middle of the screen. But this
works only if there is a paragraph in the middle. If the middle of the
destination screen happens to be in the header or the footer, or in a blank
space without a paragraph there then the cursor isn't repositioned and stays
where it was. This is rather unintuitive. It would be best if these keys never
moved the cursor at all.

I think.

AFAIR the autosave scenario was reproducible and it has been fixed.

> - Position the cursor.
> - Use the scroll wheel to scroll some pages down or up so that the cursor goes
> out of sight.
> - Press one of the arrow keys, Home, or End. Bingo! Unwanted jump. 100%
> reproducible.

So far this was not "unwanted", at least by the developers. :-) If the jump
doesn't occur, the key press will show no reaction and this is even more
confusing. A lot of applications behave the same way (e.g. Firefox that I'm
currently using to write this text).
A consistent treatment of all cursor movement keys would be fine.

As Éric pointed out, the fact that we can't reproduce "really unwanted" cursor
jumps limits our ability to fix that issue considerably, as everything we can do
is guess work.

ok, for those who can't reproduce it.

I've taken virtualbox 3.0.2 r49928, installed windows xp sp3, installed
virtualbox addons. Then I installed OOo_3.1.0_Win32Intel_install_wJRE_ru.exe 145
MB (152 642 464 bytes). (OOO310m11, build: 9399) included jre is: 1.6.0_13

Then make some simple page: write "test" text on first page, insert 3 more pages
(manual breaks), write "test N" on them.
Set cursor on the "test" word at first page, and scroll down to 4th page.
then you either scroll back and forth from page 2 to page 4 and it will
accidently jump back to the first page or you JUST CLICK on some menu item, and
it again scrolls back to first page.
also happens oftener if there is some picture/diagram or whatever on some page.
!!! It appears like unwanted jump happens on some repaint action of page.
note: there is a little chance that it wont jump back sometimes :)
note: this don't happen in ubuntu in OO 2.4 and didn't happen on OOo3.0 on my
windows xp desktop.

also for
> - Press one of the arrow keys, Home, or End. Bingo! Unwanted jump. 100%
> reproducible.
this shouldn't really be considered as unwanted scroll jump, cause it's logicaly
right thing to move the view for cursor in case of cursor movement.
BUT it's NOT right when you don't move the cursor but the view jumps back to it
sometimes.
Like i open some document, begin viewing it only by scrolling with mouse wheel,
get on some 20th page, and wtf it jumps back to the first page cause the pointer
was there. should i scroll those 20 pages again? xD

probably making text cursor to follow view scrolling (mouse scroll, vertical
scroll bar, etc) will fix this problem in boundary of one page, but dependending
of this feature realization it may get some other problems.

currenlty the jump shouldn't happen on mouse/vertical bar scrolling, menu
clicking, autosaving (some other action which calls for redraw of the view that
triggers jump back to cursor) because this complicates work with documents.

I'd like to sum up here:
- Jump when typing -> no bug. The view must be reset to where the cursor is.

- Jump when opening menu *Format* and *Insert* -> no bug. The "things" you want
to insert or format are at cursor position. The view must be reset to where the
cursor is.

@MBA: well maybe this "could" be a separated issue considering that just
intending to open a menu is NOT executing one of its commands and the view
shouldn't jump just opening this menu.
Compare with menu Insert in Wordpad...


- Jump when scrolling and *only* scrolling -> THIS is the bug we cannot
reproduce here.

I also get the jump-to-cursor on autosave. I am using Windows 7 RC, and I have
done nothing but download Open Office 3.1, install it with the standard
installation, and use it.

However, my main issue is with the jump-to-cursor location when scrolling with
the mouse wheel. If you scroll with the mouse wheel before the cursor blinks
once, you will be sent to the cursor location when you finish scrolling.

I scroll very quickly when editing documents. Taking the time to use page up or
page down, or use the scroll bar on the right of the document, would waste as
much time as waiting for the cursor to blink once does. It's only a second,
maybe, wasted each time I need to scroll somewhere else to select text, but when
this happens 60+ times in an hour, the annoyance and wasted time quickly adds up.

So PLEASE remember that users are also voting for this issue due to mouse wheel
scrolling causing jump-to-cursor-location. If there is a different issue for
that specific problem, I would appreciate being pointed to it so I can vote for
that.

Thank you,
Nathan

@coraythan: "However, my main issue is with the jump-to-cursor location when
scrolling with
the mouse wheel."

This is also the issue it is about here. :)
Everything else should be tracked in other issues.

"If you scroll with the mouse wheel *before the cursor blinks
once*"

What do you mean? The cursor blinks all the time...


Once again: there must be something else than just "installing OOo 3.1", else
we'd had already reproduced it. Something common to all your systems (a specific
mouse? Mouse settings? Zoom factor? Layout?) and that's what we are trying to
find out.

I just created two test documents, one with 4 pages full of nonsense and 
another one with the exact same content but manual page breaks. without page 
breaks, there is no unwanted jump to cursor and everything is fine. as soon as 
there is at least one page break anywhere, the bug reveals itself. just click 
somewhere near the top or bottom of the currently visible content and "scroll 
the cursor off the screen". scrolling (mouse wheel or scroll bar) has to be 
done quickly (< 0.5 s) after setting the cursor. this issue has driven me mad 
while writing my thesis :-(
but i am experiencing the developers problem in reproducing the bug right 
now ... now that i finished writing my thesis, the bug does not occur in this 
document any more ...

Created attachment 63726 [details]
document without page breaks, not showing unwanted jump to cursor

sorry for spamming the list, but i just found out something interesting. i 
intended to upload my sample documents with and without page breaks, but the 
bug does not occur in either of them! the "problem" is re-opening a document, 
which "solves" the bug.

here is another attempt to reproduce the bug:
1) open any document or create a new one
2) insert a manual page break anywhere
   => unwanted jump to cursor from now on!
3) save document and re-open
   => bug is gone

if you stop at step 2), try to undo the page break. the bug will still be 
there, even if the document has been reverted to its original state by the 
"undo".

btw, i still use OOO300m8 Build 9357

@pfadwaechter: as far as I could see you are not "spamming" (just saying "me
too!") at all but give valuable new info on how to reproduce it. :) Thanx!

According to your description it is only reproducible in a fresh (even if saved
but not reloaded) document.

Ok i did followings:
- I opened your document
- copied the 1st paragraph
- created a new document
- pasted it continuously until 14 pages had been created
- Ctrl+Home (sets the cursor at the top of the doc)
- scrolled down
-> no jump

Questions:
- Can you reproduce the problem doing exactly what I have done? (if yes, we have
overseen something)
- Which system arew you using (including window manager if you are on Unix)
- Please try the smae again in a *curent* version.
At best, test this in:
http://openoffice.bouncer.osuosl.org/?product=OOo-Dev&os=win&lang=en-US&version=DEV300_m52

I tested in OOO310m11 (=3.1rc2) on Vista.

Thank you!

@es

i think you forgot about step 2), insertion of a manual page break. in further 
tests, all kinds of manual breaks (line, column and page) lead to the bug. just 
do the same as you did before but insert a manual break anywhere before you 
test for an unwanted jump.

i was able to reproduce the bug with OOO310m11 and DEV300_m52 on "XP pro SP3 
nLite" and with DEV300_m52 on "XP pro SP2 (unmodified)".

@pfadwaechter & es:

FYI, I can reproduce this bug following pfadwaechter's instructions exactly
(OOO310m11, OS X 10.5). However, I can reproduce it even without the manual
break (as it regards saving/autosaving).

1. Open a new text document.
2. Hold down 'enter' till you're at the bottom of the page.
3. Save the document.
4. Type asdf at the bottom of the page so you have something new to save.
5. Scroll to the top of the page, and hit cmd/ctrl + S.
6. You should be jumped back to the cursor.

Isn't this a milder form, but essentially the same thing as what you're
describing, pfadwaechter?

2 pfadwaechter,

for me the bug happens both in example without manual-breaks (
jump2cursor_no-page-break.odt ) and happens when I manually insert manual breaks
at the ends of each page in that document whenever I scroll.
so it's 100% not because of manual breaks!

it just sometimes happen, sometimes not. really wierd thing.

2 es,
>> - Jump when opening menu *Format* and *Insert* -> no bug. The "things" you want
>> to insert or format are at cursor position. The view must be reset to where
the cursor is.
Well funny thing. if it is not, then you probably forgot to add unwanted jump to
Tables and Edit menus. hell yeah... i've been scrolling (read: viewing) document
and decided to insert some table somewhere i couldn't even remember. *sarcasm ends*
Normal human will surely think where he wants to insert
table/field/somethingelse first, then scroll to required position, click some
place and only then do the action.
it's not right that it scrolls when you just click some toplevel menu. but it's
right to do the scroll when user just done some action from insert/edit/table
menu. (and in case if the user didn't placed cursor to right place he'll see
what he inserted because the action triggers wanted scroll (in this case its right))
Also have you ever seen that clicking menu scrolls view back to cursor in any
other word processor?
And what if the behaviour of unwanted jump somehow connected with refreshing of
menus or whatever?

also it was a bad idea to rename the issue because there are more cases than
just mouse scrolling (e.g ANY vertical scrolling, menu clicking, and it was
firstly appeared at autosaving)
and still it scrolls/jumps back to cursor at saving/autosaving...

@javert03: "it regards saving/autosaving"

As you say, a different cause of view jump.
So please write an other issue for this.
Don't forget to mention "MAC OSX" as OS.

We are tracking here "jump on scrolling". Nothing else.

I've been working with manual breaks when I've been having all the problems with
this bug. When I tested this just now, I only saw the bug with view returning to
the cursor after I had inserted a manual break in the document. The bug does not
appear to take place if no manual break has been inserted since it was most
recently opened, even if it had manual breaks from a previous session! 

@kaker:

"it just sometimes happen, sometimes not. really wierd thing."

Refrain mentioning this. The problem is currently that it is not reproducible
with a defined scenario. So saying "it happens sometimes" doesn't bring us
further AND makes the issue useless longer.

"also it was a bad idea to rename the issue because there are more cases"

The "more cases" are different issues. That's why I changed the summary.
To focus on 1 cause.

Other causes may be defects or not (read where I say "sum up" carefully).
Write new issues for them.

Else you write to much saying "this an that" about the issue and this in a
compact 1-paragraph long unreadable sentance.

Please refrain doing this.

Just add comments which might make the problem go further.
For instance, the last comments "pfadwaechter" and "javert03" may be full of
good hints (that I will analyze later).

Your comments don't help to surrender the problem.

@coraythan:

(Why this issue is sooo long. Please people! Learn to say it short and clear!)

If I correctly understand what you say:
The issue happens when:
- *only* when a page break has been inserted in the doument
- the page break has been inserted in the current *instance* of the document
(after load or after new document)

The issue DOES NOT happen when:
- There is no page break in the document.
- There is a page break in the doc but which was already existing (saved in a
previous session) in the document.

Right?

When working in a document, if I inserted bullet points through Format -->
Bullets and Numbering, the problem began taking place. Using the quick button to
insert bullet points did not cause the return-to-cursor on mousewheel scroll bug
to occur, though.

I tested it in two new documents I created, and inserting bullets from the menu
caused the problem to begin. Inserting bullets with a quick button did not.

@es

Yes, precisely.

@coraythan:

I will have then a look at your comments from "Fri Jul 24 21:54:02 +0000 2009"
later.

But what you right now describe with the *menu*  "Format - Numbering/Bullet" is
an other problem (read my comments when I say "sum up"). So please forget it for
this issue.

@all:

Please never refer anymore to a "jump to cursor on clicking menu 'Format' or
'Insert'". This is now tracked on issue 103790.

@es

I'm sorry, I'm a little confused here.

Issue 103790 does not describe the problem I encountered with respect to
inserting manual page breaks, or inserting bullet point formatting through the
menu. 

Did you intend it to? 

I realized when you said "this issue," I may have misunderstood your meaning.
Here is exactly the problem I am experiencing and how I am able to consistently
recreate it:

1. Create a new document, or load an existing document, with at least a page of
text.

2. Make any change to the document through the Insert, Format, or Table menu. I
tested with inserting a Manual Break, changing Character properties, adding
bullet points, and inserting a table.

3. Click on any location in the document so that the cursor is in a new location. 

4. Immediately (<0.5 seconds) scroll with the mouse wheel so the cursor is no
longer on the screen. When finished scrolling, the view should jump back to the
cursor's location. (To recreate this, click to move the cursor to the top line
of the page, while scrolling down with the mouse wheel.)

2 es,
> The "more cases" are different issues. That's why I changed the summary.
> To focus on 1 cause.
Well why then you were marking other issues as dups previously? And now you're
changed your mind. This issue was about jump on autosave... now it's about jump
on scroll. funny. Should we consider creating some more issues again about
autosave, save, vertical scroll bar scrolling (oh no it's not about mouse wheel
*sob*)? lol 

you should reading more carefully as *coraythan* telling you not about jump when
you click menu item, but that after inserting more elements in page and then
beginning to scroll makes the bug appear more often. that's almost what I said
before and that's why I tell that the behaviour is somewhat random.

Just take some big document with whole bunch of different formatting, images,
diagrams, set cursor to page one and scroll down 20-30 pages - you'll 100% meet
this bug.
Also as I presented the case with clean XP install on virtual box, and the bug
easily produced there. Could it be that you cannot understand what people are
complaining about?

Also switching throught two different documents triggers scroll back to cursor
too. and you should note that it doesn't happen just when you switch, there is
1-2 second timeout before that happens. 

@MBA: Please read and comment! Thanx!

Well I'll try again to make it better now... :)

Kaker is right, I made some mistakes closing *some* issues as duplicates of this
one while I don't consider them *anymore* as duplicate.

Other thing is: the original report from "rpeckhoff" was about "jump to cursor
on save". After a while and some comments from different users it became a
general "jump to cursor" problem covering many different situations.

I believe that this annoying effect (jump to cursor) has different root causes
depending on what triggers it and cannot be fixed using 1 issues but in
different ones.

Why do I believe this?
1. The fact that I (and colleagues too) cannot reproduce the "jump on scroll"
(with or without page break) while I can reproduce other jumps (clicking on some
root menu, autosave...) makes me think those are different cases.

2. Considering FME's (an OOo developer) comments from Wed Apr 2 11:44:46:

"fme->richlv: Jump on save has been fixed with issue 2968. Jump on autosave has
been fixed with issue 81697. This issue is about some more (possibly) unwanted
jumps."

...shows that already at that rime a jump on autosave was not the same issue
(from a code point of view) as a jump on save.

Now I'd like to sum up my findings (picked up from different comments) and will
write new and separated issues if needed (MBA or OD might help!):

Tested on Vista with OOo 3.1 (310m11) and DEV 3.2 m52:

1. Jump on autosave: is still reproducible.
2. Jump on save: is still reproducible.
3. Jump on clicking on menu Format or insert: I wrote issue 103790.
4. Jump on switching forth an back between 2 OOo documents: reproducible.
5. Jump on scrolling: NOT reproducible with a new/reloaded document, with or
without page breaks, with 3 pages or 50 pages full of graphics and tables.

This last behavior is described by some users (Ex: "Kaker") as "random" = not
reproducible. Which is a big difference with the other jumps which are always
reproducible.

Now I'm waiting for developers' comments to know if I should:
- Consider *any* jump as 1 issue (I don't think so).
- keep this issue as "jump on save" and write new and clean issues for the other
cases.
- keep this issue as "jump on scrolling with the mouse wheel", try my best to
get it reproduced and write new and clean issues for the other cases.

6. Jump when clicking on the Language state in the status bar then clicking
again on it to make the pop-up menu disappear.

@es:

Thanks for your detailed explanation of this issue's status, and thanks for your
hard work consolidating all this information.

I checked again, and am able to consistently reproduce the "jump on scrolling"
with a manual page break. If you're interested, here's how:

1. Create a new text document.
2. Insert manual page break.
3. _Immediately_ scroll up till the cursor if off screen. (see below for
specifics on this step)
4. View will jump to cursor.

Step 3 must be done immediately because the jump only occurs when the user
interface is redrawn. Here's the order of events:

1. Break is inserted, and page jumps to new cursor position (this is normal).
2. User interface is redrawn. (Rulers align to new position; 'undo' and 'save'
buttons becomes usable; status bar shows new page number, etc.). When redraw is
completed, the view jumps to cursor again (this second jump is the problem).

The scrolling _must_ occur between events 1 and 2. That means if you have a
large monitor or a fast computer, you won't be able to reproduce this bug
because you won't have enough time to get the cursor off-screen. On my MacBook,
there is a ~0.5 second delay between events 1 and 2, giving me just enough time
to get the cursor off my 13" screen. It is easier to reproduce on my old Pentium
4 desktop.

To tell if you truly cannot reproduce this bug:

1. Enable View->Rulers.
2. Perform the steps above while carefully watching the rulers.
3. After inserting a page break, you should be able to watch the rulers realign
to the new position. If the rulers realign _after_ you've gotten the cursor
off-screen, and you do not experience a jump-to-cursor, then I guess we can say
this particular jump really isn't reproducible.

Anyways, that's what I think. :-D

@javert03:
- thank you for recognizing my efforts in giving a good solution to this issue! :)
- thank you for providing once again a very detailed and *analyzed* description!

Yes it could have been that! But I still cannot reproduce it the way you
describe it. :(

On *my system*: I see clearly an update of the vertical ruler (less than 0.5
sec). But even when scrolling up and losing my cursor *before* this update
happens, I don't get the jump. :(

My system: I think you are right to talk about "fast" computer and big screen
resolution because I "feel" we have here an update/timer problem which is harder
to reproduce when you have a fast system.

My system is not the best on the market (Intel Core Duo CPU with 3GHz and 2G RAM
- but, hey! Not the slowest! ;) ) and my display is done over HP w2558hc in
1920x1200 and over NVIDIA GeForce 9500GT... But it may be a reason why I cannot
reproduce it.

I have to confess that in the meantime I could YES reproduce this jump after
creating documents with 50-2000 pages with page breaks. But not in a manner
which can be *reproducible*!

It happened for me after *a while* (meaning I created a big document and didn't
touched for some minutes). When I wrote some text on a page x and scroll very
fast to page x+1.

But it remains the same good old "sometimes" because the next same created
document had no problem. :(

to be continued...

I have a large monitor, completely new computer, and have no problem reproducing
the jump-to-cursor on mouse scroll, exactly as I described it. It is consistent,
and happens every time for me after a formatting change from the menu.

Also, I have tried this on multiple computers. It happens on my computer running
Windows 7, and on my girlfriend's computer, running Vista x64. You've tried
reproducing this as I suggested, clicking so the cursor is on the very top (or
bottom) of the page, and while doing that, scrolling down (or up if it was on
the bottom)?

@coraythan:

You're right that, at least on my systems, the jump occurs with more changes
than just adding a manual break. It's not caused by _every_ change from the the
menus you mentioned, but close. For instance, Format->Change Case doesn't cause
a jump. Is that correct?

btw, I'm testing on OS X 10.5.7 and Windows XP Home SP3, both with OOO310m11.

Hi Éric,

here is a scenario 100% reproducible for me on Ubuntu 8.04 with OOo 3.1.0
(vanilla) and OOO310_m15 :

1/ open a new text document
2/ add some dummy text on several pages (I used autotext DM)
3/ insert a bookmark somewhere
4/ save the document
5/ place the cursor somewhere and do some modification, it doesn't matter if it
is before or after the bookmark
6/ scroll with the mouse wheel
7/ wait until autosave
When autosave occurs OOo jumps at cursor position (step 5).

@jbfaure: Thanx for describing again but you talk about "autosave" and that was
poin 1.) in one of my last comments and it is yes always reproducible.
What I could not reproduce was a "jump when scrolling"


@ALL: I think I've got it now! :)

As far as I can see, one of the causes of this "jump when scrolling" may be the
"3. Jump on clicking on menu Format or insert (issue 103790.)"

My scenario:
A) New Writer doc (with a big zoom where the page is not fully displayed)
B) type some characters i.e. "dsvfdvfd"
C) scroll fast down to make the text disappear and wait
-> NO jump

D) scroll back to the cursor
E) Open and close the Format menu *without* taking any action in it.
F) scroll fast down to make the text disappear and wait
-> NO jump

G) scroll back to the cursor
H) Now type some more characters
I) scroll fast down to make the text disappear and wait
-> JUMP TO CURSOR.

There might be other ways to set this internal jumps on.
In the scenario I describe 2 things are important:
- The menu format needs to have been clicked once. this is the first condition
to have a "jump-friendly" document.
- The second condition is: each time before scrolling, type some new text.


Now - as I stated before - I'm waiting to hear from DEV how they want those
findings (several issues) and if THIS issue should be "jump when saving" or
"jump when scrolling". :)

Thanx for all your contributions!

Thanks, es, for your effort!

I can reproduce your cause "Opening Format menu" with a new OOo profile.
And this issue occurs after opening the "Insert" menu too.

Every new action you do the first time then causes a jump back: inserting a new
line, inserting text, inserting a backspace, going to the next line with the
cursor or in a new position in the same line ... If you do the same action a
second time, no jump back to the cursor occurs.

I can NOT reproduce any jumps which are described in this issue without opening
the Format or Insert menu before. Also this has nothing to do with autosave as
far as I know.

P.S. In my normal OOo profile for "production", the weird thing is that I don't
have to open the Insert or Format menu to experience this problem. Maybe we have
to wait for a fix to test this with "production" profiles again.

Ok, after discussing all this with the development those are all apparently
different issues.

So I wrote new issues depending on the manipulation that triggers the jump.

(Sorry for all issues I or colleagues used to close as duplicate of this one,
writing new clean issues goes faster as finding, reopening and reworking old ones)

Here are the issues:

- Jump to cursor on Autosave: Issue 103835
- Jump to cursor on Save: Issue 103836
- Jump to cursor ON clicking the menu Format or Insert:  issue 103790.
- Jump to cursor when scrolling with the mouse wheel after having clicked menu
Format or Insert: issue 22453 (the current issue).
- Jump to cursor on switching between OOo documents: issue 103839
- Jump to cursor on closing the language bar pop-up menu: issue 103838

I will re-post my last detailed description and send to DEV.

Folks please! Considering the numbers of comments already done in this issue,
please let us now fix it without adding any new "it happens to me too!" :)

The issue is now reproducible from our side.

Thanx a lot! :)

@OS: as discussed with MBA, reassigning to you.
It is very similar to issue 103790 but it NOT a duplicate.
(Please ask me if it not clear :) )

Please try to fix this for 3.3.

Description:
- New Writer doc (with a big zoom where the page is not fully displayed)
- type some characters i.e. "dsvfdvfd"
- scroll fast down to make the text disappear and wait
-> NO jump

- scroll back to the cursor
- Open and close the Format or Insert menu *without* taking any action in it.
- scroll fast down to make the text disappear and wait
-> NO jump

- scroll back to the cursor
- Now type some more characters
- scroll fast down to make the text disappear and wait
-> JUMP TO CURSOR.

I cannot see when this situation does not exist for almost every situation.

It's getting worst everytime!...I think I have compiz on, that's why.

*** Issue 104857 has been marked as a duplicate of this issue. ***

If it can be of any help, I am using OOo 3.1.1 (official Sun build) on mac OS X
10.5  and this issue happens very, very frequently -- so much that trying to
scroll with the mouse becomes a frustrating fight against OO. I suspect there is
something in the mac port that triggers this auto-scrolling quite often (since
NeoOffice does it much, much less, I assume it's linked to the Sun mac port)

Perhaps this should be two bug reports? I can understand the discussion about
arrow keys (and personally I don't mind that the arrow keys jump me back).

But the bug I cannot understand is scrolling back for no reason - when I have
done nothing but use the mouse wheel and suddenly I'm zapped back to the place I
just scrolled away from - if I wanted to see it, why would I have scrolled away
from it?

eg I am going through a document to check that all the headers have the header
style applied.

1. Click on header, apply header style.

2. Quickly scroll down to next header (with the mouse wheel).

  Before I have a chance to click on the next header, the view jumps back to the
first header. (within 1 second of step 1).

I have not pressed any keys, all I have done is scrolled.

I'm seeing this right now on Mac OSX with OOo 3.1.1 and I used to see it way
back with OOo 2 on various versions of Ubuntu linux.

@es: Sorry, got a new one for you, with the same setup (zoomed window, scroll
cursor off screen) as the other menu-click issues. Select File > Properties.
Jump to cursor happens as soon as the Properties dialog is painted.
I await your pleasure as to whether to handle it (a) here, (b) in one of the
spawned issues, or (c) as a new one. --tj

@tjfrazier: file a new issue for this. set the correct version, OS and so on...
But as you describe it I cannot reproduce it in m61 on Vista.

Please consider the expression "jump to cursor" as the word "crash": it's not
because you have a crash that it's the same for everybody.

So now ONCE AGAIN - this issue has an exact summary, is confirmed, has a
developper as owner, has a target and some of its avatars are mentioned in my
comments so now I expect nobody but the developer and I to write comments in it!

Stop you all commenting here! This issue has been accepted: thank you!

Most probably already fixed as issue 103839

*** This issue has been marked as a duplicate of 103839 ***

duplicate -> closed