Bug 139747 - Saving document resets scroll focus
Summary: Saving document resets scroll focus
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.4.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-18 16:14 UTC by david.cortes.rivera
Modified: 2021-01-21 07:20 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
scroll_resets (934.92 KB, image/gif)
2021-01-20 19:11 UTC, david.cortes.rivera
Details
file_to_reproduce_bug (4.25 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-01-20 19:12 UTC, david.cortes.rivera
Details

Note You need to log in before you can comment on or make changes to this bug.
Description david.cortes.rivera 2021-01-18 16:14:06 UTC
When working on a scrollable single-page docx document, if the writing focus is put somewhere in the beginning of the page and I then scroll down and save, will automatically move screen focus to where the writing focus is, which is not what one wants to happen when saving.

Steps to reproduce:
- Create a docx document, write something on it to fill a page.
- Zoom in enough to make it scrollable.
- Put the writing focus (the blinking line) somewhere near the beginning.
- Scroll down near the end of the page.
- Press Ctrl + S

Expected behavior: should save the document, while focus (both the blinking line and the screen visibility) remains as it was.

Actual behavior: takes screen focus to the blinking line.

Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 16; OS: Linux 5.10; UI render: default; VCL: kf5
Locale: en-US (en_US.UTF-8); UI: en-US
Debian package version: 1:7.0.4-3
Calc: threaded
Comment 1 V Stuart Foote 2021-01-18 20:43:29 UTC
Can not confirm.  On a single page document zoomed so as to enable scroll bar, the text cursor scrolled out of the view, a <ctrl>+S save does not move the view. The text cursor remains where it was.

Setting user ident in Tools -> Options -> User Data has no effect here.

This was an issue in the past, see also bug 95797 but have not noted any recurrence. 

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 1a167625314bf36b735176ed488e6ba9b5e9b675
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 2 Telesto 2021-01-19 15:01:47 UTC
Please add an example file (and/or screencast)..The unwanted scrolling still present in number of cases, but save should be fine (comment 1)

Setting to NEEDINFO
Comment 3 david.cortes.rivera 2021-01-20 19:11:11 UTC
Created attachment 169060 [details]
scroll_resets

Added an example gif showing the problem in action.
Comment 4 david.cortes.rivera 2021-01-20 19:12:49 UTC
Created attachment 169061 [details]
file_to_reproduce_bug

Added also the file from the video above.
Comment 5 Telesto 2021-01-20 19:31:40 UTC
@Buovjaga
You have kf5 desktop environment as primarily, secondary system or whatever..

Would you mind to test? Fine on Windows

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 6ee7a3b2c0565c2871d32d704cb2899445b9f88d
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 6 Buovjaga 2021-01-21 07:20:53 UTC
It jumps back with 7.0.4, but not with 7.2

Arch Linux 64-bit
Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
7.0.4-2
Calc: threaded

Arch Linux 64-bit
Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: 3ff95c8df6be9aa01aef5c663ee2ffa9881193d4
CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 20 January 2021