Bug 135244 - Document (still) scrolling to cursor position on different occurrences
Summary: Document (still) scrolling to cursor position on different occurrences
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0
Keywords:
: 116907 (view as bug list)
Depends on:
Blocks: Writer-View-Jumps Scrolling-PageUpDown
  Show dependency treegraph
 
Reported: 2020-07-28 18:19 UTC by Telesto
Modified: 2022-04-08 10:44 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (12.76 KB, application/vnd.oasis.opendocument.text)
2020-07-28 18:20 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-07-28 18:19:28 UTC
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
Comment 1 Telesto 2020-07-28 18:20:20 UTC
Created attachment 163710 [details]
Example file

1. Set cursor on page 1
2. Scroll down
3. File -> Save As -> File name Save
Comment 2 Telesto 2020-07-28 18:22:40 UTC
Adding UX expert for confirmation.. and maybe making it an easy hack; there are some examples how to solve this..
Comment 3 Heiko Tietze 2020-07-29 10:07:29 UTC
(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
Comment 4 Telesto 2020-07-29 10:10:51 UTC
(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
Comment 5 Heiko Tietze 2020-07-29 10:16:14 UTC
I see it as a feature when actions execute at the cursor focus first rather than doing things in the background.
Comment 6 Telesto 2020-07-29 10:25:49 UTC
(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..
Comment 7 Telesto 2020-07-29 10:28:37 UTC
@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
Comment 8 Heiko Tietze 2020-07-29 10:31:54 UTC
(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.
Comment 9 Mike Kaganski 2020-07-29 10:37:05 UTC
(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.
Comment 10 Mike Kaganski 2020-07-29 10:42:33 UTC
(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).
Comment 11 Mike Kaganski 2020-07-29 10:43:27 UTC
... 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.
Comment 12 Mike Kaganski 2020-07-29 15:29:45 UTC
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.
Comment 13 Telesto 2020-07-29 16:12:13 UTC
(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
Comment 14 Mike Kaganski 2020-07-29 16:14:35 UTC
(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.
Comment 15 Telesto 2020-07-29 18:51:24 UTC
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
Comment 16 Mike Kaganski 2020-07-29 21:15:28 UTC
> 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.
Comment 17 Telesto 2020-07-29 21:17:10 UTC
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
Comment 18 Telesto 2020-07-29 21:31:00 UTC
(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.
Comment 19 Mike Kaganski 2020-07-29 21:32:22 UTC
(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.
Comment 20 Mike Kaganski 2020-07-29 21:37:04 UTC
(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.
Comment 21 Telesto 2020-07-29 21:53:53 UTC
(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.
Comment 22 Mike Kaganski 2020-07-29 21:54:18 UTC
(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.
Comment 23 Mike Kaganski 2020-07-29 21:57:03 UTC
(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.
Comment 24 Commit Notification 2020-07-29 22:03:18 UTC
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.
Comment 25 Commit Notification 2020-07-29 22:04:29 UTC
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.
Comment 26 Commit Notification 2020-07-30 05:59:14 UTC
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.
Comment 27 Commit Notification 2020-07-30 06:34:39 UTC
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.
Comment 28 NISZ LibreOffice Team 2020-07-30 08:10:49 UTC
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
Comment 29 NISZ LibreOffice Team 2020-07-30 08:13:51 UTC
(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
Comment 30 Mike Kaganski 2020-07-30 08:14:31 UTC
Please use this bug as an easy hack with multiple small items; code pointers are in comment 12, and the commit notifications.

Unassigning myself.
Comment 31 Telesto 2020-09-26 12:29:31 UTC
@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!
Comment 32 Buovjaga 2020-09-29 13:59:00 UTC
*** Bug 116907 has been marked as a duplicate of this bug. ***
Comment 33 sdc.blanco 2022-04-08 10:44:34 UTC
(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