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: RESOLVED DUPLICATE of bug 46988
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
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: 2024-04-19 09:31 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
test ODT (12.04 KB, application/vnd.oasis.opendocument.text)
2024-04-06 08:07 UTC, Stéphane Guillou (stragu)
Details

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
Comment 6 QA Administrators 2021-04-02 03:47:36 UTC Comment hidden (obsolete)
Comment 7 sdc.blanco 2021-04-11 19:25:44 UTC
Basic problem when "clone formatting" is selected is mouse movement, especially from canvas to toolbars above or below canvas moves the canvas.

Should only move canvas with sliders and mouse wheel, not mouse movement.

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 35a06c67701eacb85591b61c948233a4f0ad238b
CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-US (en_DK); UI: en-US
Calc: CL
Comment 8 QA Administrators 2023-04-12 03:21:08 UTC Comment hidden (obsolete)
Comment 9 sdc.blanco 2023-04-28 09:16:21 UTC
repro

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: fc6806c4be8585ce0d35a6b581bf8b3dbf858500
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: af-ZA (da_DK); UI: en-US
Calc: CL threaded
Comment 10 Stéphane Guillou (stragu) 2024-04-06 08:07:10 UTC
Created attachment 193538 [details]
test ODT

The original summary was:

"screen focus changes from bottom of page to top of page when using clone formatting"
...which is similar to bug 57818, but we are talking about text/paragraphs here.

The view port "follows" the clone target at or preceding the cursor, and if the closest paragraph is out of the view port, the view jumps.

Please test in attached document:
1. Open document
2. Make sure view only show bottom of the first page
3. Select highlighted text
4. Click Clone Formatting in toolbar
5. Try to apply the cloned formatting to the last item in list

Result: as you move the pointer down, the view jumps to the top of the first page.

In my opinion, the current behaviour makes _some_ sense: we need to see which paragraph or selection will get the format when clicking, which is denoted by a vertical dashed marker.
But the jump described in the steps above is annoying.

UX/Design team, what do you think?

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 30c6e51fc9cb0fa864e1755271343d847fcced25
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded
Comment 11 Stéphane Guillou (stragu) 2024-04-06 08:10:28 UTC
(Same in OOo 3.3 -> inherited)

(Noting that I disagree with the current summary, unless I'm missing something: scrolling with the mouse _should_ be allowed, because one wants to apply the format anywhere. Or am I missing something, Seth?)
Comment 12 Heiko Tietze 2024-04-08 10:53:59 UTC
(In reply to Stéphane Guillou (stragu) from comment #10)
> we need to see which paragraph or selection will get the format
> when clicking, which is denoted by a vertical dashed marker.
Not so sure about this. Doesn't the faint dash marker follow the mouse cursor? Or am I missing some a11y feature here?
Comment 13 Michael Weghorn 2024-04-08 11:06:56 UTC
(In reply to Heiko Tietze from comment #12)
> Not so sure about this. Doesn't the faint dash marker follow the mouse
> cursor? Or am I missing some a11y feature here?

I don't see any particular a11y feature here.
Comment 14 Stéphane Guillou (stragu) 2024-04-12 15:49:06 UTC
(In reply to Heiko Tietze from comment #12)
> (In reply to Stéphane Guillou (stragu) from comment #10)
> > we need to see which paragraph or selection will get the format
> > when clicking, which is denoted by a vertical dashed marker.
> Not so sure about this. Doesn't the faint dash marker follow the mouse
> cursor?
It does, but if there is no paragraph under the cursor, the dashed marker "lands" on the closest paragraph above it (test it in the attachment).
Comment 15 Heiko Tietze 2024-04-19 08:03:12 UTC
We discussed the topic in the design meeting.

The issue happens only when moving slowly from top. A smooth scrolling could help. We suggest to make this report a duplicate of bug 46988.
Comment 16 Stéphane Guillou (stragu) 2024-04-19 09:31:11 UTC
(In reply to Heiko Tietze from comment #15)
> We discussed the topic in the design meeting.
> 
> The issue happens only when moving slowly from top. A smooth scrolling could
> help. We suggest to make this report a duplicate of bug 46988.
Sounds good to me as a compromise.

*** This bug has been marked as a duplicate of bug 46988 ***