Bug 106374 - VIEWING: Document canvas view jumps to beginning of index after updating
Summary: VIEWING: Document canvas view jumps to beginning of index after updating
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Mike Kaganski
Whiteboard: target:6.2.0
Keywords: topicUI
Depends on:
Blocks: Writer-View-Jumps
  Show dependency treegraph
Reported: 2017-03-06 23:13 UTC by Thomas Lendo
Modified: 2018-10-08 07:37 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

File with long ToC to test the jump issue (16.55 KB, application/vnd.oasis.opendocument.text)
2017-03-08 14:54 UTC, Thomas Lendo

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Lendo 2017-03-06 23:13:29 UTC
If you have a large index or ToC and update it, the view jumps to the beginning
of the index.

This is annoying if you have a large index and you want to monitor a change after update - you can't see the update process and what changed live because the view changes.

Expected result: Retain the view position after updating an index.

Tested with LibO
Build ID: 1:5.3.0~rc3-0ubuntu1~trusty1.1
CPU Threads: 2; OS Version: Linux 3.13; UI Render: default; VCL: gtk2; Layout Engine: new; 
Locale: de-AT (de_DE.UTF-8); Calc: group

Also tested with LibO on Windows 8.
It's an old bug that also existed in OpenOffice.org.
Comment 1 Xisco Faulí 2017-03-08 12:26:15 UTC
Hello Thomas,

Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Comment 2 Thomas Lendo 2017-03-08 14:54:49 UTC
Created attachment 131753 [details]
File with long ToC to test the jump issue

Steps to reproduce:

1. Open the attached Writer document.
2. Scroll down to the end of ToC at the first page.
3. Right-click at ToC and choose "Update Index" in the context menu.

Actual result:

The document canvas view jumps up to the beginning of the ToC. You can't see what changed at the bottom part of the ToC during update. (Real world use case: My detailed ToC in a master document fills 4 A4 pages.)

Expected result:

The document canvas view shouldn't change when updating a ToC. It's not clear to as user like me why that happens.
Comment 3 Xisco Faulí 2017-03-12 16:42:44 UTC
Adding 'needsUXEval' to see whether it's the expected behaviour or not...
Comment 4 Heiko Tietze 2017-03-12 20:40:12 UTC
The issue is similar to bug 41063 (and maybe to bug 95797 where kendy solved a regression). 

I don't see any reason to change the cursor position on save. At least from the user POV it must stick to the current place. Stuart added some more situations, i.e. auto save and restore edit view as well as reopen that has to be considered.

PS: Haven't tested the issue myself, so keep UNCONFIRMED.
Comment 5 Xisco Faulí 2017-03-14 08:56:09 UTC
Thanks Heiko.
Let's move it to NEW then, as the behaviour should be consistent throughout the application.
Comment 6 Thomas Lendo 2017-03-26 06:58:35 UTC
Just FYI I collected some jump issues in the wiki: https://wiki.documentfoundation.org/User:Lendo/Usability#Annoying_Jump_Issues
Comment 7 Heiko Tietze 2017-03-26 09:04:31 UTC Comment hidden (no-value)
Comment 8 QA Administrators 2018-03-27 02:28:23 UTC Comment hidden (obsolete)
Comment 9 Thomas Lendo 2018-04-03 14:02:03 UTC
Still reproducible in Version: (x64)
Build ID: 8e0eb015e74775b9bf02326ffd7b67e83ad6c60d
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-04-03_03:53:38
Locale: de-AT (de_AT); Calc: CL
Comment 10 Mike Kaganski 2018-07-26 09:24:28 UTC
This one is easy to change, just

>         case FN_UPDATE_CUR_TOX:
>         {
>             const SwTOXBase* pBase = m_pWrtShell->GetCurTOX();
>             if(pBase)
>             {
>+                const bool bWasLocked = m_pWrtShell->IsViewLocked();
>+                m_pWrtShell->LockView(true);
>                 m_pWrtShell->StartAction();
>                 if(TOX_INDEX == pBase->GetType())
>                     m_pWrtShell->ApplyAutoMark();
>                 m_pWrtShell->UpdateTableOf( *pBase );
>                 m_pWrtShell->EndAction();
>+                if (!bWasLocked)
>+                    m_pWrtShell->LockView(false);
>             }
>         }
>         break;

to void SwView::Execute(SfxRequest &rReq) in C:\lo\core\sw\source\uibase\uiview\view2.cxx. Note though, that the update not only jumps the view; it also moves the cursor position to the position just before the index field (which is natural: the cursor is placed inside the field, e.g. by right-clicking; the content of the field is regenerated - i.e., it is destroyed and recreated again; so the position is lost in the process; and the content of the field might be very different after the update). So is the change consistent from UX PoV?
Comment 11 Heiko Tietze 2018-07-26 10:25:54 UTC
(In reply to Mike Kaganski from comment #10)
> So is the change consistent from UX PoV?

Sounds acceptable. With all your tips it's definitely an easy hack, or will you submit the patch yourself?
Comment 12 Mike Kaganski 2018-07-26 11:09:08 UTC
(In reply to Heiko Tietze from comment #11)
> With all your tips it's definitely an easy hack, or will
> you submit the patch yourself?

Sigh... I didn't think about that; to be easy-hack, I shouldn't have posted the patch itself. Sorry :) - will post the patch myself then.
Comment 13 Mike Kaganski 2018-07-26 11:18:19 UTC
Comment 14 Commit Notification 2018-07-30 14:42:58 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":


tdf#106374: lock view when updating index

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 15 Thomas Lendo 2018-10-08 07:37:20 UTC
Mike, thank you for your patch!

Verified on Version: (x64)
Build ID: e46f8a9a4e3c5b0542c0813b476b449f3af8d607
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-07_23:36:50
Locale: de-AT (de_AT); Calc: CL