Bug Hunting Session
Bug 95266 - [VIEWING] While having the cursor in a comment and view scrolled elsewhere, after switching back from another window the view jumps to the cursor
Summary: [VIEWING] While having the cursor in a comment and view scrolled elsewhere, a...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: x86-64 (AMD64) All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-View-Jumps
  Show dependency treegraph
 
Reported: 2015-10-23 05:02 UTC by Luke Kendall
Modified: 2019-01-12 08:02 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kendall 2015-10-23 05:02:01 UTC
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...
Comment 1 Luke Kendall 2015-10-23 05:37:18 UTC
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.
Comment 2 Luke Kendall 2015-10-23 07:25:28 UTC
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.
Comment 3 Buovjaga 2015-10-24 17:02:04 UTC
Repro.

Win 7 Pro 64-bit, Version: 5.0.2.2 (x64)
Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe
Locale: fi-FI (fi_FI)
Comment 4 Luke Kendall 2015-11-22 02:02:30 UTC
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.
Comment 5 Luke Kendall 2015-11-22 02:18:38 UTC
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.
Comment 6 QA Administrators 2017-01-03 19:35:46 UTC Comment hidden (obsolete)
Comment 7 Cor Nouws 2018-04-15 15:52:29 UTC
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-x86_64@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 ;)
Comment 8 Buovjaga 2018-04-15 16:05:29 UTC Comment hidden (obsolete)
Comment 9 Buovjaga 2018-04-15 17:45:41 UTC
(In reply to Cor Nouws from comment #7)
> 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-x86_64@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 ;)

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
Comment 10 Luke Kendall 2018-04-16 04:23:04 UTC
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.
Comment 11 Buovjaga 2018-04-16 06:50:11 UTC
(In reply to Luke Kendall from comment #10)
> 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?
Comment 12 Luke Kendall 2018-04-19 06:02:39 UTC
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.
Comment 13 Buovjaga 2018-04-22 13:42:17 UTC
(In reply to Luke Kendall from comment #12)
> 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.

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.
Comment 14 Luke Kendall 2018-05-02 13:37:54 UTC
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.
Comment 15 Luke Kendall 2018-05-02 13:56:30 UTC
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.
Comment 16 Cor Nouws 2018-05-03 11:36:46 UTC Comment hidden (obsolete)
Comment 17 Cor Nouws 2018-05-03 11:37:07 UTC
(In reply to Buovjaga from comment #9)

> Cor: did you test with a DOCX file?

No, an odt. can reproduce it straight forward.
Comment 18 Luke Kendall 2018-08-06 08:07:51 UTC
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)
Comment 19 Luke Kendall 2018-08-12 07:24:21 UTC
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.
Comment 20 Luke Kendall 2018-08-29 06:57:59 UTC
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
Comment 21 Luke Kendall 2018-12-08 08:03:18 UTC
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.
Comment 22 Luke Kendall 2019-01-12 08:02:40 UTC
Still happening in 6.1.3.2.
The steps needed to have the cursor click into the text you clicked in, and the view NOT jump away to the previous insertion point, is easy to get wrong.

I had some success jumping via F&R to the comment I wanted, then, after it jumped away, working my way back there via F&R, then clicking in the main body of the document on that comment's page, then when the view jumped away, working my way back, AGAIN, with F&R, then clicking in the body of the comment.

The user experience of this bug is very much what I think Charlie Brown felt like, each time Lucy snatched the football away, in the Peanuts cartoon strip. I'll be very happy when this bug is fixed.