[Libreoffice-bugs] [Bug 95266] New: Sometimes scrolls to a point away from the cursor position

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

Bug ID: 95266
Summary: Sometimes scrolls to a point away from the cursor
position
Product: LibreOffice
Version: 5.0.2.2 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: libreoffice-***@lists.freedesktop.org
Reporter: ***@zeta.org.au

This has been happening for a while, it's not new in series 5. You can scroll
to some point in a document, then click down with the mouse and sweep out some
text, only for LO to scroll/jump to a different point in the document and set
the insertion point at an unexpected place.
E.g. just now I had scrolled the document so the text I wanted to change was
roughly in the middle of the screen, and I clicked down to select two words.
Instantly, LO scrolled away from their and in fact opened up the footer and set
the insertion point against the page number!
My feeling in the past was that perhaps it would jump back to where the
insertion point had last been left, in the doc, when you scrolled away - but on
this occasion, I have no clue why LO jumped down half a screen and opened the
footer area.
I'll try to stay more alert to the issue, and see if I can see a pattern behind
it happening. I have a feeling it involves comments, for some reason...

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #1 from Luke Kendall <***@zeta.org.au> ---
I do think it's related to comments. It just happened again - jumped back over
a page. In trying to reproduce it, I point the insertion point into a comment,
then scrolled to a new page. I changed focus to a 2nd doc to copy some text
(and a comment) and clicked back to the 1st document: on this occasion (and
reproducibly), the document automatically jumps back to the page with the
comment where the insertion point is.

Yes, that's when it happens: if the insertion point is in a comment and you
scroll away from that point, and then change focus to (e.g. copy some text)
from a 2nd document, if you then simply click into the text in the 1st
document, the instant the 1st doc regains focus, LO jumps back to the page
where the comment with the insertion point is.

Quite reproducible.

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #2 from Luke Kendall <***@zeta.org.au> ---
It's actually rather annoying. If you aren't watching what you're typing, you
can easily end up with text inserted in a strange place. I just had a phrase
added to the header, until I noticed.

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

Beluga <***@suomi24.fi> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
CC| |***@suomi24.fi
Summary|Sometimes scrolls to a |Cursor inside comment,
|point away from the cursor |scrolled down: position
|position |wrong after switching back
| |from another document
Ever confirmed|0 |1
OS|Linux (All) |All
Severity|normal |minor

--- Comment #3 from Beluga <***@suomi24.fi> ---
Repro.

Win 7 Pro 64-bit, Version: 5.0.2.2 (x64)
Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe
Locale: fi-FI (fi_FI)

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #4 from Luke Kendall <***@zeta.org.au> ---
It also happens if, after scrolling away from the insertion point, you Ctrl-S
to save the document. All your scrolling is lost and you're thrown back to the
page with the comment. Which is annoying if you spent 30 seconds or more in
getting to the right point.

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #5 from Luke Kendall <***@zeta.org.au> ---
Oh, and I just tested: it also does it if you have the insertion point in the
body of the document, and then scroll down from there: if you Ctrl-S save, it
jumps back to where the insertion point is. It's really very annoying.

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #6 from QA Administrators <qa-***@libreoffice.org> ---
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today,
LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed
bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this
bug report. During that time, it's possible that the bug has been fixed, or the
details of the problem have changed. We'd really appreciate your help in
getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of
LibreOffice
(5.1.6 or 5.2.3 https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of
LibreOffice and
your operating system, and any changes you see in the bug behavior

If the bug is NOT present, please set the bug's Status field to
RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular
meaning that is not
appropriate in this case)


If you want to do more to help you can test to see if your issue is a
REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your
bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat:
http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug-20170103

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

Telesto <***@surfxs.nl> changed:

What |Removed |Added
----------------------------------------------------------------------------
Blocks| |106773


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=106773
[Bug 106773] [META] Writer document canvas view jump issues

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

Cor Nouws <***@nouenoff.nl> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@nouenoff.nl
Summary|Cursor inside comment, |After switching back from
|scrolled down: position |another document, the view
|wrong after switching back |changes so that the cursor
|from another document |is in the view, also if the
| |view was different (same as
| |with (auto-) safe)

--- Comment #7 from Cor Nouws <***@nouenoff.nl> ---
Changing summary, according to various comments.

Still present in Version: 6.1.0.0.alpha0+
Build ID: dc823f5fa4a5d2eca56297b9045e5962536c00f9
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2;
TinderBox: Linux-rpm_deb-***@70-TDF, Branch:master, Time:
2018-04-10_23:32:35
Locale: nl-NL (nl_NL.UTF-8); Calc: group

Didn't happen in 'good old' 3.3.0 ;)

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

Buovjaga <***@suomi24.fi> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords| |bibisectRequest, regression
Summary|After switching back from |After switching back from
|another document, the view |another document, the view
|changes so that the cursor |changes so that the cursor
|is in the view, also if the |is in the view, also if the
|view was different (same as |view was different (same as
|with (auto-) safe) |with (auto-) save)

--- Comment #8 from Buovjaga <***@suomi24.fi> ---
True, not yet in 3.6.7.

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #9 from Buovjaga <***@suomi24.fi> ---
(In reply to Cor Nouws from comment #7)

Post by b***@bugs.documentfoundation.org
Changing summary, according to various comments.
Still present in Version: 6.1.0.0.alpha0+
Build ID: dc823f5fa4a5d2eca56297b9045e5962536c00f9
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2;
2018-04-10_23:32:35
Locale: nl-NL (nl_NL.UTF-8); Calc: group
Didn't happen in 'good old' 3.3.0 ;)

Btw. does not happen to me with ODT - only with DOCX, just like bug 116907. The
ODT fix was bug 95797.
Cor: did you test with a DOCX file?

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: c8c74a0b4ca6f3a3619f423b6548c80c52392ae0
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk2;
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on April 15th 2018

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #10 from Luke Kendall <***@zeta.org.au> ---
It happens very reproducibly with just .odt files.
Certainly if your insertion point is in a comment in a .odt doc: if you set the
insertion point in a comment, and scroll many pages away, then click into a 2nd
doc (.odt) and then just select the window frame for the 1st doc, it scrolls
back to the page with the comment with the cursor insertion point.

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

Buovjaga <***@suomi24.fi> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|After switching back from |After switching back from
|another document, the view |another document, the view
|changes so that the cursor |changes so that the cursor
|is in the view, also if the |is in the view, also if the
|view was different (same as |view was different
|with (auto-) save) |

--- Comment #11 from Buovjaga <***@suomi24.fi> ---
(In reply to Luke Kendall from comment #10)

Post by b***@bugs.documentfoundation.org
It happens very reproducibly with just .odt files.
Certainly if your insertion point is in a comment in a .odt doc: if you set
the insertion point in a comment, and scroll many pages away, then click
into a 2nd doc (.odt) and then just select the window frame for the 1st doc,
it scrolls back to the page with the comment with the cursor insertion point.

I could reproduce this, but not in a 100% straightforward way: I had to click
in and out of the comment, then scroll away.

Without a comment I cannot reproduce.

Actually, I was carried away by the addition of (same as with (auto-) save) so
yesterday I tested only the saving.

Cor: based on my experience, I would revert your summary change to the
original. Can you really reproduce without being in a comment in the other
document?

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #12 from Luke Kendall <***@zeta.org.au> ---
I just had it happen to me within a single .odt document, my current book MS.
I had edited a comment, and I think left the cursor in there, then scrolled
back to an earlier point in the document, looking for a piece I wanted to
rewrite.
I found it, and then clicked into the main doc text I wanted to change - and
the view instantly jumped 8 pages forward to the page with the comment I'd just
modified.

I struggled to find a way to reproduce it.

But I just managed to, and the key thing is to bring some other window to
focus.
Indeed, I think I now have the sequence, since I found that using the mouse
wheel to scroll in a document (relying on the fact you don't need to refocus
the window for that to work), is almost certainly what I'd done.

So my steps to reproduce are:

1. Single .odt doc.
2. Put cursor selection point in a comment.
3. Scroll away using any means you like (except Page forward/back keys on
keyboard, obviously)
4. Focus on some other window - e.g. Mail, chat window - especially one that
doesn't overlap your .odt window, so you feel no need to refocus that window.
5. Move mouse back over .odt doc and continue scrolling
6. Click with left mouse button to the point you wish to edit

Result:
Instead of the insertion point/cursor appearing at that point, the view jumps
away to the page with the comment, and the insertion point becomes the position
you clicked on the screen, but in that other page of your document.

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

Buovjaga <***@suomi24.fi> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords|bibisectRequest, regression |
Version|5.0.2.2 release |3.5.0 release
Summary|After switching back from |While having the cursor in
|another document, the view |a comment and view scrolled
|changes so that the cursor |elsewhere, after switching
|is in the view, also if the |back from another window
|view was different |the view jumps to the
| |cursor

--- Comment #13 from Buovjaga <***@suomi24.fi> ---
(In reply to Luke Kendall from comment #12)

Post by b***@bugs.documentfoundation.org
1. Single .odt doc.
2. Put cursor selection point in a comment.
3. Scroll away using any means you like (except Page forward/back keys on
keyboard, obviously)
4. Focus on some other window - e.g. Mail, chat window - especially one that
doesn't overlap your .odt window, so you feel no need to refocus that window.
5. Move mouse back over .odt doc and continue scrolling
6. Click with left mouse button to the point you wish to edit
Instead of the insertion point/cursor appearing at that point, the view
jumps away to the page with the comment, and the insertion point becomes the
position you clicked on the screen, but in that other page of your document.

I did some re-testing and this is actually already seen in 3.5.0 (tested on
Win). 3.3.0 has some glitch that makes it impossible to scroll while the focus
is in a comment.

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #14 from Luke Kendall <***@zeta.org.au> ---
The bug is really irritating when you use Find & Replace to jump around in your
document - e.g. I leave marker text (###) to indicate "to do" areas.

I'm very glad F&R has an option to allow you to search including comments; but
when the match is in a comment, if you click on the document title to focus the
window, the view jump back to the last place the cursor was at, rather than
staying on the page with the current match! You have to click into the body of
the document to get the page to "stay put".

I've also found that when the match is in a comment, the view often doesn't
refresh correctly: only the page body is drawn, and the comments are not
rendered in any way until you focus the document window, click in the body of
the doc, or use the mouse wheel to scroll the page a little.

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #15 from Luke Kendall <***@zeta.org.au> ---
I'm on a tight deadline, so instead of filing a separate bug report, I'll note
that if you use F&R with "Search in comments" ticked, and then change to using
the up/down search buttons for other text via the quick search box at the
bottom of the document window, all is well - until you click the "up" search
arrow. When you do that, the "Search in comments" checkbox is cleared in the
F&R panel.

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #16 from Cor Nouws <***@nouenoff.nl> ---
(In reply to Buovjaga from comment #9)

Post by b***@bugs.documentfoundation.org
Cor: did you test with a DOCX file?

No. and odt. can reproduce it straight forward.

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #17 from Cor Nouws <***@nouenoff.nl> ---
(In reply to Buovjaga from comment #9)

Post by b***@bugs.documentfoundation.org
Cor: did you test with a DOCX file?

No, an odt. can reproduce it straight forward.

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #18 from Luke Kendall <***@zeta.org.au> ---
I also just noticed a related issue, I think. I was using Find & Replace to
search for a particular marker string I had added to some of the comments, to
keep track of time passing in the story. I was editing the "days passed" I had
noted in the comments.
I found that after editing the days noted in one comment, and using Find Next
to move to the next relevant comment, when I tried to click into the
now-visible comment that was found, LO jumped the view back to the last comment
I had just edited, *reasonably* reproducibly. All in a single document.

Also, if you reverse search direction (e.g. change from Finding Next to Finding
Previous), the position in the document jumps away, to the last comment found.

I had that happening very reproducibly while writing this up - for a while.
Then, not so reproducibly. Frequently, though.

I also tried window focus changes to this web browser window, but focus change
doesn't seem to be a strong factor. (This is in LO 6.0.5.2)

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #19 from Luke Kendall <***@zeta.org.au> ---
It definitely seems to me Writer fights itself with the cursor focus. E.g. I
had a comment on one page, and two on the following page. With the insertion
point in the earlier page comment, but that page scrolled out of view so only
the follwoing page showed, I clicked on the comment's drop-down menu icon and
chose "Delete comment".
The view changed to scroll the earlier comment into view before marking the
comment as deleted. Same when I did the same deletion on the next comment on
that second page.

It seems to me there's logic in Writer that assumes the current operation is
going to always apply to wherever the 'insertion point' is in the document - or
at least, when that point is in a comment. So when the user instead does some
other operation that is independent of that, it alters the user's view quite
wrongly.

On some occasions, I've spent ten minutes manually scrolling through an MS,
looking for something, finally found it, and then clicked to start making the
edit I want, only to have the focus jump a hundred pages away.

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #20 from Luke Kendall <***@zeta.org.au> ---
Yes, it's pretty infuriating, using a search string that will take you to
different comments, that you'd like to edit. After finding the one you want,
and clicking in it to start editing it, I find it's more likely Writer will
jump away from it to the comment you last edited.
I just spent a minute finding the comment I wanted and clicking in it, only to
have it jump away to the wrong comment. It did that about four times in a row.

Version: 6.0.5.2
Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2;
Locale: en-GB (en_AU.UTF-8); Calc: group

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

Luke Kendall <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|While having the cursor in |[VIEWING] While having the
|a comment and view scrolled |cursor in a comment and
|elsewhere, after switching |view scrolled elsewhere,
|back from another window |after switching back from
|the view jumps to the |another window the view
|cursor |jumps to the cursor

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=95266

--- Comment #21 from Luke Kendall <***@gmail.com> ---
I've had to switch to using SAL_USE_VCLPLUGIN=gen to avoid the glib2 bug that
makes LO use 100% CPU time.

I thought it might be helpful to know the bug is present in that older UI too.
The view will repeatedly jump away, back to the last cursor insertion point,
unless I scroll the main document view up and down and then try to click into
it. Otherwise it just repeatedly jumps away, if you try to click into a
comment or click into the main document view.