Bug 136539 - Unwanted scroll when changing something in the Paragraph Window using edit blue page break line (see comment 11)
Summary: Unwanted scroll when changing something in the Paragraph Window using edit bl...
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks: Writer-View-Jumps
  Show dependency treegraph
 
Reported: 2020-09-07 09:12 UTC by Telesto
Modified: 2022-05-05 18:27 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Example file (568.53 KB, application/vnd.oasis.opendocument.text)
2020-09-07 09:17 UTC, Telesto
Details
Example file 2 (126.20 KB, application/vnd.oasis.opendocument.text)
2020-09-07 09:33 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-09-07 09:12:20 UTC
Description:
Unwanted scroll when changing something in the Paragraph Window using edit blue header with the cursor on a different page

Steps to Reproduce:
1. Open the attached file
2. Scroll to the middle of the file
3. Put cursor somewhere
4. Scroll up to page 1/2
5. Hoover over the blue edit header bar -> Edit page break
6. Change the page style

Actual Results:
Scrolls to cursor position; 

Expected Results:
Not so


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: e8b8e7be0b2ad693224cd94062a55610eb69df7e
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 1 Telesto 2020-09-07 09:15:09 UTC
@Mike
Are we at a point where this qualify's as easy hack with plenty of examples around? 

See bug 135244
Comment 2 Telesto 2020-09-07 09:17:01 UTC
Created attachment 165221 [details]
Example file
Comment 3 Mike Kaganski 2020-09-07 09:20:03 UTC
(In reply to Telesto from comment #1)

We are - from the PoV of changing this. However, I'm not so sure about confirming this as a bug at all. Changing page style changes the layout of all the following text. You have a cursor at the position that changes layout because of your actions. You are moved to that point - rightfully IMO.
Comment 4 Telesto 2020-09-07 09:33:30 UTC
Created attachment 165225 [details]
Example file 2

> We are - from the PoV of changing this. However, I'm not so sure about
> confirming this as a bug at all. Changing page style changes the layout of
> all the following text. You have a cursor at the position that changes
> layout because of your actions. You are moved to that point - rightfully IMO.

I'm not following you're argument.. :-). Slightly modified example
1. Open the attached file (slightly modified version)
2. Scroll to last page & place cursor there
3. Scroll up to page 1/2
4. Blue header bar -> Edit header
5. Switch for area tab (as it can be done)
6. Change enable color & press OK

Change made at paragraph page 2. Landing at last page.. Similar happens when changing page style.. And if wants to scroll it should stop at last page with that page style.. not totally unrelated one.. only because of some cursor

So not totally following the objection. I'm in general allergic to scrolling. Even if the change is made somewhere else (except for CTRL+Z CTRL+Y maybe; but might be a matter of taste).
Comment 5 Mike Kaganski 2020-09-07 09:40:59 UTC
(In reply to Telesto from comment #4)

The same with any change you do here. And no, it shouldn't "stop at last page with that page style". It should show you where the cursor is, if that place is re-layouted as the result of your actions.

For the obvious example, let's continue with "change page style" case. Say, you have page 2 till page 5 as Style1 (A4); and page 6 and followng Style2 (A4). You put cursor somewhere on page 10, go to page 1/2, and change style of page at your page break to be Style3 (sized A3). This would make your pages a till 5 (4 pages in total) to becomr pages 2 till 4 (3 pages in total); and your cursor that was on page 10, is not on page 9. This is the change!
Comment 6 Telesto 2020-09-07 10:01:41 UTC
(In reply to Mike Kaganski from comment #5)
> (In reply to Telesto from comment #4)
> 
> The same with any change you do here. And no, it shouldn't "stop at last
> page with that page style". It should show you where the cursor is, if that
> place is re-layouted as the result of your actions.
> 
> For the obvious example, let's continue with "change page style" case. Say,
> you have page 2 till page 5 as Style1 (A4); and page 6 and followng Style2
> (A4). You put cursor somewhere on page 10, go to page 1/2, and change style
> of page at your page break to be Style3 (sized A3). This would make your
> pages a till 5 (4 pages in total) to becomr pages 2 till 4 (3 pages in
> total); and your cursor that was on page 10, is not on page 9. This is the
> change!

It should show you where the cursor is, if that place is re-layouted as the result of your actions.

For the exotic say color of paragraph case this simply not true. There is no change at all at cursor position. 

For they page style difference.. Page style is changed all over the place. So they 'cursor' position is as random as staying on the page. 

Another exception is press CTRL+A at top of the document. The cursor is at the bottom but shows still they top page (which is desired, but doesn't fit the principle)

If you want to see what you're doing, you scroll to the position where the change happens. If you have the cursor at some random spot, the scroll to cursor thing is simply frustrating annoying as it only disturbing workflow; creates surprises & you need to find the original page again.

So question is more what's the general rule & what the exception. I tend to stay put, except for.. CTRL+Z CTRL+Y CTRL+V 

As I don't see the usability.. we still need some kind of poll system build in to LibreOffice. Infobar pointing to a poll.. where an example is illustrated with they question what people would expect :-)

Discussing this kind of topic in some obscure bug tracker ticket ...
Comment 7 Mike Kaganski 2020-09-07 10:03:17 UTC
(In reply to Mike Kaganski from comment #5)
> and your cursor that was on page 10, is not on page 9.

I meant "is *now* on page 9".

Any other change, like spacing, font, borders, etc, can result in changes. And at any such change, application simply drops old layout and creates a new, so your cursor ends up on a new layout - even for the cases when the place happens to be the same.
Comment 8 Mike Kaganski 2020-09-07 10:06:22 UTC Comment hidden (off-topic)
Comment 9 Telesto 2020-09-07 10:45:02 UTC Comment hidden (off-topic)
Comment 10 Heiko Tietze 2020-09-18 13:10:34 UTC Comment hidden (off-topic)
Comment 11 Thomas Lendo 2020-09-26 21:02:59 UTC
I looked over the comments very quickly and my 2 cents are:

As far as I understood, to test this issue I've to go to the last page and put the cursor somewhere on it (caret blinks). Then I've to scroll up to the first pages and click on one of the blue page break lines. There somewhat opens to "Edit page break..." and "Delete page break".

And here I've to make a break in my test:
Here is nothing about page style or header!
What are you people talking about?

Further in the test:
I click on "Edit page break..." and the paragraph dialog (not paragraph style dialog!) opens. I go to Area tab, choose a color and click OK.

Result:
* With 7.1 the view jumps back to where the caret is positioned. The colored paragraph on the pages before isnt' visible.
* With 6.0 the view doesn't move to the last page and the colored paragraph is visible.

I tested the second attached document with the Linux master build for 7.1 from yesterday and version 6.0.7.3.

My point of view:
The behavior of 6.0 feels 'right' as on the last page, where the caret is, nothing has changed. So it isn't necessary that the user is taken there.
Comment 12 Telesto 2020-09-26 21:13:06 UTC Comment hidden (off-topic)
Comment 13 Thomas Lendo 2020-09-27 15:43:06 UTC
Reproduced with Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US
Calc: threaded

Set to 'regression' as it worked in another way in version 6.0.7.3. Maybe version between 6.0 and 7.0 are also affected.

@Mike Kaganski:
I haven't read your and Telestos conversation, but as I said in comment 11 I would set this bug report to NEW as the behavior in 6.0 feels more 'right'. I say this as part of the UX team. I know that there is much 'discussable' in such bug reports, but here it's clear for me that something (paragraph after page break) has changed that has nothing to do with the paragraph or view area where the caret is positioned. Therefore a jump to the caret isn't necessary.
Comment 14 Telesto 2020-09-27 18:08:54 UTC
@Caolan
You solved; bug 134439 and bug 135636. This is bug number 3

author	Jan Holesovsky <kendy@collabora.com>	2018-01-23 18:13:01 +0100
committer	Jan Holesovsky <kendy@collabora.com>	2018-01-24 11:45:52 +0100
commit c3a085d22742f88e91ff92f319a26d6e8d1d9a98 (patch)
tree 9f84d93e9a2822760b60730e9c6130a31e0302db
parent 3bbf8d0a9b9e36299c889d8252d9a2b068f17ff6 (diff)
lokdialog: Convert the Table -> Properties... to async exec.

Bit of a (pointless) squabble about this, as I missed out the regression aspect..

I believe - with Thomas - that the old behavior should restored. The behavior isn't intentional introduced. However, you might ask Mike at the DEV chat. It might be that he is ignoring my bug reports (e-mail filter).
Comment 15 Caolán McNamara 2020-09-28 14:36:40 UTC
has it been definitely bisected to that commit, because that commit affects the table dialog while the dialog I see on page boundaries 1/2 2/3 is the paragraph dialog
Comment 16 Telesto 2020-09-28 15:01:15 UTC
(In reply to Caolán McNamara from comment #15)
> has it been definitely bisected to that commit, because that commit affects
> the table dialog while the dialog I see on page boundaries 1/2 2/3 is the
> paragraph dialog

Dammit, exposed.. Was a copy paste.. but had bug 134439 comment 9 (and 10) in mind.. I started the bibisect in 6.1 but it started crashing so it reminded me. 

However don't notice the difference between Table/Paragraph dialog.. So it's likely this commit:

author	Jan Holesovsky <kendy@collabora.com>	2018-01-16 18:54:19 +0100
committer	Jan Holesovsky <kendy@collabora.com>	2018-01-17 08:48:02 +0100
commit 34527cec54ca634b831cfa5ac1098c4046818ac3 (patch)
tree d75a2e21ab0d71953a65334d1376ec916ea0221e
parent ce9594d40a8d72370624b045761df4e0078d601e (diff)
lokdialog: Convert the Format -> Paragraph... dialog to async exec.
Change-Id: I47ec0ca95a713a7485b936aea7d7351970c9d967

FWIW.. haven't checked it (except i'm sure it started in 6.1)
Comment 17 Dieter 2021-09-14 17:36:17 UTC
Jan, can you have a look at it?

cc: Jan Holesovsky
Comment 18 Xisco Faulí 2022-05-02 14:02:08 UTC
Dear Telesto,
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Comment 19 Jean-Baptiste Faure 2022-05-05 15:45:35 UTC
For me the current behavior is the right one. Otherwise how do you go back to the cursor position if you do not remember in which page it is ? You need to type something at risk to overwrite valid text if something was selected.
From my PoV, showing the cursor position is the rule, showing something else is the exception.

Best regards. JBF