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...
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.
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.
Repro. Win 7 Pro 64-bit, Version: 5.0.2.2 (x64) Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale: fi-FI (fi_FI)
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.
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.
** 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
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 ;)
True, not yet in 3.6.7. Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
(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
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.
(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?
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.
(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.
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.
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.
(In reply to Buovjaga from comment #9) > Cor: did you test with a DOCX file? No. and odt. can reproduce it straight forward.
(In reply to Buovjaga from comment #9) > Cor: did you test with a DOCX file? No, an odt. can reproduce it straight forward.
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)
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.
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
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.
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.
This very annoying and frustrating bug is still present in: Version: 6.3.4.2 Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: x11; Locale: en-GB (en_AU.UTF-8); UI-Language: en-US Calc: threaded Just noting that using Find & Replace, when you click *on a comment* on the visible page, the view often (70% of the time?) jumps far away from the text you just found, back to some match of that same string at a completely different place in the document. I had to keep redoing the searches; eventually the view wouldn't jump away and I could make the change I wanted. Sometimes (20% of the time?) the view jumps even when you try to click into the body of the document rather than on a comment, but the bug occurs far more frequently if you try to click on a comment. It doesn't seem to matter whether the matched text is in a comment or in the body of the document.
Still present in 6.4.6.2 It is definitely related to comments. I was adding comments with a marker string throughout my document, using several Find & Replace searches, to add the same marker string comment for some editing I'm about to do. If I left the cursor in the text of the comment I had just added, then clicked "Find Next" in the F&R panel, if I then clicked into the main body of the document (to add another marker string comment to the next problem point), the main body of the document would usually jump back to the page with the previous comment. If instead of leaving the cursor in the text of the comment I had just added, I clicked back into the body of the document on the currently visible page, the F&R followed by selection of text and insertion of a new comment worked reliably. The problem appears to be caused by leaving the insertion point set in a comment when you navigate to a new place in the document (by scrolling or by searching): when you try to click into the document text, the displayed view jumps back to the page with the comment where the insertion point was.
Dear Luke Kendall, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug