Bug 99608 - Using clone formatting enables scrolling with the mouse -- but it shouldn't
Summary: Using clone formatting enables scrolling with the mouse -- but it shouldn't
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.7.2 release
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-View-Jumps Clone-Formatting
  Show dependency treegraph
 
Reported: 2016-05-01 15:17 UTC by sdc.blanco
Modified: 2019-04-02 22:29 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sdc.blanco 2016-05-01 15:17:25 UTC
Windows 7, LO 4.4.7.2  and LO 5.1.3.1

Procedure:

1. Use an existing document (or make a document with some text on top and two lines further down. 

2.  Scroll down, so that the two lines are visible, but not the top line.
(may have to adjust window size)

3. Set cursor on one of the bottom lines.

4. Click Clone formatting icon in Toolbar

5. When I move the mouse back to the document, the screen jumps to (almost) the top of the page.  (There are variations in what happens, but the critical point is that the screen view changes.)

6. Click off the Clone formatting icon  (i.e., without using the format).

7. Screen view returns to the original.

Expected behavior:  The screen should not change position when moving the mouse over the document, after clicking the Clone Formatting icon

Perhaps this is a "feature"?  It seems that when "clone formatting" is chosen, then the document position can be changed on the screen with the mouse alone. 
I would expect in "clone formatting mode" that the screen to remain stable (as when the normal cursor is set), and any positioning done with the slider bar.
Comment 1 Buovjaga 2016-05-06 13:51:59 UTC
Repro, except step 7 does not happen for me.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.2.0.0.alpha1+
Build ID: 540fee2dc7553152914f7f1d8a41921e765087ef
CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8)
Built on April 30th 2016
Comment 2 QA Administrators 2017-05-22 13:40:47 UTC Comment hidden (obsolete)
Comment 3 sdc.blanco 2017-05-24 19:59:35 UTC
Problem (or feature) still present.

Still a problem with:

Version: 5.3.3.2
Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
Locale: da-DK (da_DK); Calc: group

New (better?) description.

1. Use a file that has more lines than can be shown in the window.

2. Set the cursor in the window (where that are lines above the cursor that are not visible in the window).

3. Select "Clone formatting"

4.  Use the mouse.

5.  Notice that it is possible to scroll up and down (and left/right if the window is small enough).

In my opinion, this is a bug  (because it makes it more or less impossible to use the clone formatting, because the canvas jumps around.

As described before, the window should remain stable, unless the slider bars are used.

6.  Do not use Clone formatting, but unselect it.  The window returns to where the cursor was originally set.  (If you have scrolled up in the file, then it will jump back to where the cursor is)  (This is probably how it should be.)
Comment 4 QA Administrators 2019-04-02 02:49:29 UTC Comment hidden (obsolete)
Comment 5 sdc.blanco 2019-04-02 22:29:20 UTC
The basic problem is still that mouse movement scrolls the canvas up and down (or left and right if the window is more narrow than the width of the document), when "clone formatting" is selected.  

Also, if the cursor is set on a line that is close to the top (or bottom) of the screen, then after selecting clone formatting, the screen jumps several lines (to move the line with the cursor away from the top (or bottom).

Version: 6.1.5.2 (x64)
Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: da-DK (da_DK); Calc: CL