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
Scrolls to cursor position;
User Profile Reset: No
Version: 126.96.36.199.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
Are we at a point where this qualify's as easy hack with plenty of examples around?
See bug 135244
Created attachment 165221 [details]
(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.
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).
(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!
(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
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 ...
(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.
Any such poll is destinied to be biased, mostly answered by those who are not satisfied, with all those who are okay with the current state mostly ignoring it. Only telemetry may give you something substantial.
(In reply to Mike Kaganski from comment #8)
> Any such poll is destinied to be biased, mostly answered by those who are
> not satisfied, with all those who are okay with the current state mostly
> ignoring it. Only telemetry may give you something substantial.
There is indeed a truth in it .. partly to be mitigated.. to show only info bar inquiry not about the topic.. So people are already opening the site.. which obviously has a wizard to click next (before the topic appears). So not 'screening' if you're interested.. and move on; idea. OK you only reach the people taking the time for it..
The poll questions can be manipulated too. So you can certainly room to get a desired outcome.. or make it more easily to happen
Currently it's decided in the back chambers of LibreOffice. At dev department, UX department, QA department or some by incident or some history nobody knows. So don't think the current approach is 'optimal' either. I certainly doubt some UX decisions (no offence Heiko). As hard to grasp which type of user you have; how they use LibreOffice etc. If you don't use page breaks, you won't run into this.
Telemetry; no experience with the data it produces. Never seen the analytics. Nor what it registers (and what not).
I don't trust telemetry blindly, IMHO. It's a tool/instrument which can give insights and feedback. But I wouldn't use it exclusively either.
Their a simple different sources of information. Ideally you use multiple. And some point it will by simply trying. I assume lots of research was been don one start menu of Windows 8. UX did go even so far to remove the old one (as people are habitual). However backfired quite badly. Negative reviews; lots of complains. Created a niche for all sorts of StartisBack apps.
The Ribbon menu bars was also new with Office 2007, but they succeeded to get it in. Now 75% wants it all over the place, and 25 % dislikes it (my estimate.. no real numbers).
No offense taken, would love to do more usability testing but have to spend all time in reading tickets ;-). Don't get the point here. Blue edit header bar... not in the file, not on hoover.
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.
* 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 188.8.131.52.
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.
(In reply to Thomas Lendo from comment #11)
You're description fits.
With 'blue edit header I actually meant: "Blue page break line" (couldn't find the proper terminology)
With change page style I probably revering to Text Flow Page Style setting (however in essence every change would be valid) which I attempt to 'correct' with comment 4) So yes, no page style involved..
And yes, this thing qualify's a (very) bad report to express steps
Reproduced with Version: 184.108.40.206
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
Set to 'regression' as it worked in another way in version 220.127.116.11. Maybe version between 6.0 and 7.0 are also affected.
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.
You solved; bug 134439 and bug 135636. This is bug number 3
author Jan Holesovsky <email@example.com> 2018-01-23 18:13:01 +0100
committer Jan Holesovsky <firstname.lastname@example.org> 2018-01-24 11:45:52 +0100
commit c3a085d22742f88e91ff92f319a26d6e8d1d9a98 (patch)
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).
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
(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 <email@example.com> 2018-01-16 18:54:19 +0100
committer Jan Holesovsky <firstname.lastname@example.org> 2018-01-17 08:48:02 +0100
commit 34527cec54ca634b831cfa5ac1098c4046818ac3 (patch)
parent ce9594d40a8d72370624b045761df4e0078d601e (diff)
lokdialog: Convert the Format -> Paragraph... dialog to async exec.
FWIW.. haven't checked it (except i'm sure it started in 6.1)
Jan, can you have a look at it?
cc: Jan Holesovsky
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
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