Created attachment 168810 [details] Example file from Writer This is split off from bug #107870 When a change tracked document has many changes, turning on/off the changes positions the view to the cursors position. Steps to reproduce: 1. Open attached file 2. Position the cursor to the paragraph “Place cursor here” on page 1. 3. Scroll to page 4 to the paragraph “WATCH THIS” 4. Choose View – Track Changes Actual results: View moves from page 4 to page 1 where the cursor is. Expected results: View stays on page 4. LibreOffice details: Version: 7.2.0.0.alpha0+ (x64) Build ID: 8e691505d4675b878b30bd00cd2e4fb4f794f0ef 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
Created attachment 168811 [details] Screenshot of the document before turning off the display of tracked changes View is on page 4
Created attachment 168812 [details] Screenshot of the problem in Writer View went to page 1
So what would be the expected behavior exactly? 1. Say, the document has long text runs removed; so with changes shown, the page count is 5, while when they are not shown, the page count is 3. You are looking at the document with changes shown. The cursor is in page 1. The view is on page 4. You turn off viewing of changes. What should happen? 2. The same as with #1, but you are looking at some text on page 3. As the result of disabling view of changes, part of that specific text moves to page 1, and part to page 2. What do you expect: to keep viewing page 3 (with different text on it), or to see page 2 (with part of text that you saw initially), or page 1 (with another other part)? 3. Say, you have cursor inside a removed part when changes are shown. You are viewing some different part of text, and then you disable viewing of changes. Your cursor changes the position (it is no more in the middle of a change). Do you expect that you do not see this change of cursor position? These are just some cases of possible problems, but in general, I believe that this case is perfectly working at the moment. Showing/hiding changes is changing the layout of the document; it's impossible to create a reasonable definition of what is "current viewing position" in this case.
In principle pro 'no scroll' without overseeing the implications as stated in comment 3.
(In reply to Telesto from comment #4) > without overseeing the implications /me is wondering if those "no one looks at the whole picture when creating local patches" were serious, or just a handy tool to make one's arguments look solid, but easily avoided when "seeing the whole picture" obviously means admitting that own PoV is flaky.
(In reply to Mike Kaganski from comment #5) > (In reply to Telesto from comment #4) I'm supporting the idea seen from case by case basis based on 'end-user'. The scroll simply annoying. I'm trying to admit I'm not the all seeing eye; with global picture in front of me. In law there is always the risk of 'flood gates'. So giving in to claim a will open doors - another 20 cases - which look next to similar. And if you lack a proper demarcation criterion you going through a rabbit hole. As advocates keep sending in new cases which are pretty similar. The judges will stop moving the borders at some point.. after doing this in multiple times in different directions.. The end-result we an arbitrary outcome nobody can explain.. Except by historical reasons, and the need to stop debate. So simply reject any new case to change view. Not because the 'merits of the case' but simply by frustration and not knowing how to do it else. Currently I would go for case by case basis. As I dislike the current status quo. The jumping simply annoying. I have a preference for consistency. [Say jumping to cursor all the time] However this rule not working, IMHO. I'm happy to throw that out of the window. So tendency to go with what 'feels right'. Which with some 'reasoning' backing it. I don't think we can have simple rule in advance. But simply walk through on case by case basis. Maybe an global rule appears of time (complex systems/emergence). Or we take a time-out.. (as illustrated by flood-gate). But currently we aren't there yet, IMHO. You added few cases.. which obviously need an answer. In separately and seeing in context of comment 0. I haven't tried it yet, what should be reasonable in your case. Which probably even debatable again :-(. --- Another matter which must be included is obviously the topic of complexity scope/ and maintaining. From user perspective case by case most lovely outcome. However not sure if 'every' area being governed by different code. Or that changing it for case A means we change it implicitly for C D and E too. Which we might want (fine; nobody complains), or does the opposite (problematic) Nor do I now how this can be maintained easily. Case by case solution is more case by case code.. Doesn't make the code easier to read, I predict [my coding skills are 0]. And I have no clue if there coding strategy's to make it as easy as possible for developers. The latter is obviously the 'developer perspective'. I - as a user - have the tendency to prefer my experience. Not carrying about who has the fun of building an maintaining it; that's not my problem.. But well that's kind of throwing of the fence approach.. I can't really evaluate the developer side of this topic. Except acknowledging the presence..
According to some competitive analysis and to the user request, I think, we need the followings: 1. switch off followed a switch on (and vice versa) must restore the original view position. 2. switch off/switch on must give the original view position, if it that is still visible wholly or partially. 3. if the original view will be invisible, switch off must give the view position next to the hidden redline (similar to the case of the cursor position in a tracked deletion).
Dear László Németh, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.