Description: Document (still) scrolling to cursor position on different occurrences They issue has been solved for auto-save; manual save; closing the print preview. Steps to Reproduce: 1. Open the attached file 2. Scroll down dragging the horizontal scroll bar (or any other way not triggering the cursor) 3. File -> Save As Press Export PDF button and export somewhere open the Print dialog followed by cancel opening closing the spell dialog Edit -> Track changes -> Record Insert Textbox - Followed by CTRL+Z Update fields The behavior is probably ok for: Format Character & Format Paragraph behavior Actual Results: Unwanted scrolling Expected Results: No scrolling IMHO Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 163710 [details] Example file 1. Set cursor on page 1 2. Scroll down 3. File -> Save As -> File name Save
Adding UX expert for confirmation.. and maybe making it an easy hack; there are some examples how to solve this..
(In reply to Telesto from comment #0) > 3. > File -> Save As > Press Export PDF button and export somewhere > open the Print dialog followed by cancel > opening closing the spell dialog > Edit -> Track changes -> Record > Insert Textbox - Followed by CTRL+Z > Update fields Cannot follow this instruction. In general, last cursor position is saved not the scrollbar. Meaning you have to put the cursor on page 3 or so to get back to this position after reloading. => WFM
(In reply to Heiko Tietze from comment #3) > (In reply to Telesto from comment #0) > > 3. > > File -> Save As > > Press Export PDF button and export somewhere > > open the Print dialog followed by cancel > > opening closing the spell dialog > > Edit -> Track changes -> Record > > Insert Textbox - Followed by CTRL+Z > > Update fields > > Cannot follow this instruction. In general, last cursor position is saved > not the scrollbar. Meaning you have to put the cursor on page 3 or so to get > back to this position after reloading. => WFM Pretty easy 1. Make sure the cursor is on page 1 2. Scroll down to some position in the middle & Enable for example Track Changes 3. Document will scroll up to top (position of the cursor) Same happens for File -> Save As -> Format & file name). One of the other options in the list
I see it as a feature when actions execute at the cursor focus first rather than doing things in the background.
(In reply to Heiko Tietze from comment #5) > I see it as a feature when actions execute at the cursor focus first rather > than doing things in the background. Not following.. surely not a feature. It wasn't a feature for autosave or for pressing save with they cursor an a different page (which got solved). And for example the Print Preview is honouring the position too..
@Mike This more or less a follow up on they issue you solved for auto-save and pressing save -> scrolling to cursor position I'm seeing some other cases where scrolling to cursor position should be disabled, ideally; IMHO
(In reply to Telesto from comment #6) > (In reply to Heiko Tietze from comment #5) > > I see it as a feature... > > Not following.. If you modify content or execute functions related to the actual position it should be in focus.
(In reply to Telesto from comment #7) > @Mike > This more or less a follow up on they issue you solved for auto-save and > pressing save -> scrolling to cursor position It would be super-nice if every time anyone writes some - *any* - reference, that person had a reflex to insert the relevant link, like > a follow up on they issue you solved *in tdf#41063* ... ... because likely that person saw something (a commit? a bug?) that allowed that person to make that conclusion, mentioning which would help others to not waste time searching for the same information themselves.
(In reply to Telesto from comment #0) > 3. > File -> Save As > Press Export PDF button and export somewhere > open the Print dialog followed by cancel > opening closing the spell dialog > Edit -> Track changes -> Record > Insert Textbox - Followed by CTRL+Z > Update fields > > The behavior is probably ok for: Format Character & Format Paragraph > behavior I didn't check the steps, so speaking only based on description. I agree that it's wrong with "File -> Save As", "Press Export PDF button and export somewhere", "open the Print dialog followed by cancel", "Edit -> Track changes -> Record". I disagree that this should be changed for "opening closing the spell dialog", "Insert Textbox - Followed by CTRL+Z", "Update fields". Any change in document content must re-position the view to show the change (or at least part of the change).
... and for "opening closing the spell dialog", the dialog is designed to show the relevant position. It's OK for it to re-position the view.
https://gerrit.libreoffice.org/c/core/+/99714 tdf#135244 fixes PDF export case. https://gerrit.libreoffice.org/c/core/+/99715 is for print dialog. I couldn't repro the problem with File->Save As - well, because it was fixed in tdf#41063. And after looking into Edit -> Track changes -> Record case, I see that it's simply general case of changing track changing options - including view/hide - which may change the view; so jumping to the cursor is a reasonable thing to do in this case. FTR: if one wants to fix some case, one needs to debug what is the call stack leading to the jump: put a breakpoint inside SwViewShell::MakeVisible (to ScrollMDI). Then find a place in the call stack that is reasonable to create a SfxObjectShell::LockAllViews to guard the place.
(In reply to Mike Kaganski from comment #12) > https://gerrit.libreoffice.org/c/core/+/99714 tdf#135244 fixes PDF export > case. > https://gerrit.libreoffice.org/c/core/+/99715 is for print dialog. > > I couldn't repro the problem with File->Save As - well, because it was fixed > in tdf#41063. Should have been more specific :-). This happens when saving as RTF/DOCX (apparently not when saving as DOC or ODT) Actually the scroll is still around for regular save in those cases too
(In reply to Telesto from comment #13) > > I couldn't repro the problem with File->Save As - well, because it was fixed > > in tdf#41063. > > Should have been more specific :-). This happens when saving as RTF/DOCX > (apparently not when saving as DOC or ODT) > > Actually the scroll is still around for regular save in those cases too https://gerrit.libreoffice.org/c/core/+/99714 fixes that, too.
Next case which might qualify A) Tick the highlighting tool & Press ESC to exit the bucked B). Sidebar -> Styles Panel -> Paragraph style -> Select a style & Right Click modify (only for paragraph style.. rest doesn't scroll) C. Sidebar -> Page -> Tick header or footer checkbox D) Tools -> Word Count E) Edit -> Track Changes -> Manage Dialog F) Tools -> Footnotes and Endnotes -> Make a change & press OK Sorry to not report everything in a single run.. didn't look through everything quite thoroughly they first time
> A) Tick the highlighting tool & Press ESC to exit the bucked No. You have entered an edit mode - allowing you to apply something you selected. It rightfully shows you the selection. > B). Sidebar -> Styles Panel -> Paragraph style -> Select a style & Right > Click modify (only for paragraph style.. rest doesn't scroll) Possibly; needs checking. > C. Sidebar -> Page -> Tick header or footer checkbox No - it changes document; your pagination may have changed, your cursor position moved, it's OK to re-position you. > D) Tools -> Word Count Yes > E) Edit -> Track Changes -> Manage Dialog Most possibly that's OK (needs checking just in case). > F) Tools -> Footnotes and Endnotes -> Make a change & press OK Same as C. Modifying footnotes is modifying document.
Sidebar -> Styles Panel -> Paragraph style -> Select a style & Right Click modify (only for paragraph style.. rest doesn't scroll) Not true.. go to say page style chapter 1 & change background color & press OK
(In reply to Telesto from comment #17) > Sidebar -> Styles Panel -> Paragraph style -> Select a style & Right Click > modify (only for paragraph style.. rest doesn't scroll) > > > Not true.. go to say page style chapter 1 & change background color & press > OK For the record on this one; yes the document changes.. however, the cursor & the change don't need to be at the same position.. So cursor on page 1 while being at chapter 5 position and making a page style changes means jumping to page 1 A) Tick the highlighting tool & Press ESC to exit the bucked -> A user case.. you're scrolling through a document.. highlighting stuff... you did it on page 5 the last time.. currently you're on page 10.. you notice.. nothing to highlight anymore. You press ESC. Jumping to page 5 If they last highlighting is on page 5, and you're on page 5 and press ESC nothing will change. So not seeing the object.. Currently ESC does 2 things.. disabling the bucket & causing a scroll (if the cursor is on a different page). I maybe overlooking a case where this could go wrong; but I currently can't think of one. I'm only seeing a benefit :-) > F) Tools -> Footnotes and Endnotes -> Make a change & press OK -> Say 5 page document.. (The first footnote is on page 5 (you're at that position) Cursor on page 1. Footnotes and Endnotes -> Make a change & press OK means jumping to page 1. Not sure about the logic in this case. If a change "Footnotes and Endnotes" would cause a jump to a footnote, OK. However this isn't (luckily) the case.
(In reply to Telesto from comment #17) > Not true.. go to say page style chapter 1 & change background color & press > OK It's perfectly OK to scroll back on any document change. The problem is when it does that for paragraphs just showing the dialog.
(In reply to Telesto from comment #18) > A) Tick the highlighting tool & Press ESC to exit the bucked > > -> A user case.. you're scrolling through a document.. highlighting stuff... > you did it on page 5 the last time.. currently you're on page 10.. you > notice.. nothing to highlight anymore. You press ESC. Jumping to page 5 Aha, so the problem is not at the moment of pressing the bucket, but at the moment of escape. Having very verbose steps helps. I stopped looking at this case as soon as I saw it jumping to cursor when pressing the bucket button. Agree.
(In reply to Mike Kaganski from comment #19) > Sidebar -> Styles Panel -> Paragraph style -> Select a style & Right Click > modify (only for paragraph style.. rest doesn't scroll) > > Not true.. go to say page style chapter 1 & change background color & press > OK > It's perfectly OK to scroll back on any document change. The problem is when > it does that for paragraphs just showing the dialog. Maybe I should be bit more specific (I will learn this at some point). "Not True' was referring to "only for paragraph style.. rest doesn't scroll" They Example file has Chapter page styles. If the cursor is on page 1, and you scroll to (lets take a different one) chapter 3, go to sidebar -> styles deck -> Page styles -> Right Click they chapter 3 page style -> Add a Background Color and press OK.. you end up at page 1... About the paragraph style modification.. You can modify anything.. so not actually a style in use.. it will still jump to they page where the cursor is. If they still is actually used, it still doesn't mean that the position of cursor being equivalent to position of the change.
(In reply to Mike Kaganski from comment #20) > Aha, so the problem is not at the moment of pressing the bucket, but at the > moment of escape. Having very verbose steps helps. I stopped looking at this > case as soon as I saw it jumping to cursor when pressing the bucket button. > > Agree. But the code that gets called here explicitly wants to reposition the view: https://git.libreoffice.org/core/+/master/sw/source/uibase/docvw/edtwin.cxx#4142. No idea what are the reasoning here; will not change it now.
(In reply to Telesto from comment #21) > About the paragraph style modification.. You can modify anything.. so not > actually a style in use.. it will still jump to they page where the cursor > is. If they still is actually used, it still doesn't mean that the position > of cursor being equivalent to position of the change. Any change. In anything in the document. Including something that is not used at the moment, like page style which has no instances. It's still a document change. And there's no need to make long calculations to be sure if it changed or not; if it changed before or after; if the change relates to cursor or no. Any change is OK to relocate you.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2036db5ecd227f97e0e5ab403de61b80fff93c38 tdf#135244: move LockAllViews to SfxObjectShell It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1486f96317aa6eac34ddb7ef4e1c64824bb269b4 tdf#135244: prevent jumping to cursor at document render It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a5be8e97b7699c7d12fa3ae5404af7b2eb50fafb tdf#135244: prevent jumping when generating drop caps preview It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d6ce2c0500ab026ba131782365a41da93794196f tdf#135244: don't jump when updating counts It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Some more cases: * Switch the example document to multiple pages view or book view ; then position the cursor in the middle of the document. Switch back to one pages view: view will jump forward in the document. Switch back to multiple pages or book view, and view goes back to cursor. For example in book view from Chapter 5 I see it jump to Chapter 2. Does not happen when switching between multiple pages and book views. * Put the Writer window to full screen size, then switch the example document to multiple pages view and position the cursor in the middle of document. Switch the Writer window to non-full screen size. The view will jump to an earlier point in the document, for example I see it go from Chapter 5 to Chapter 1. Switch the Writer window back to full screen size and the view jumps back to the cursor. This happens only with multiple pages view, not with single pages or book view. Both these happen on todays nightly build: Version: 7.1.0.0.alpha0+ (x86) Build ID: <buildversion> CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL
(In reply to NISZ LibreOffice Team from comment #28) > Build ID: <buildversion> No idea what's up with this now, according to https://dev-builds.libreoffice.org/daily/master/current.html the time stamp is: 2020-07-30 03:19:57
Please use this bug as an easy hack with multiple small items; code pointers are in comment 12, and the commit notifications. Unassigning myself.
@Mike Please throw in a RESOLVED FIXED here.. Will split every unwanted scroll to different bug report.. Which can be assessed and fixed/ individually. And also thanks for the solving a number of those!
*** Bug 116907 has been marked as a duplicate of this bug. ***
(In reply to NISZ LibreOffice Team from comment #28) > Some more cases: > * Switch the example document to multiple pages view or book view ; then Now reported as bug 137045 > * Put the Writer window to full screen size, then switch the example Now reported as bug 137046
Dear Telesto, 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