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
@Mike Are we at a point where this qualify's as easy hack with plenty of examples around? See bug 135244
Created attachment 165221 [details] Example file
(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 > 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 ...
(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. 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.
(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: 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.
@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).
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 <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)
Jan, can you have a look at it? cc: Jan Holesovsky
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
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
Dear Telesto, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Telesto, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp
The issue is still the same: Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: ce60a3dd4dbff0dcb5b82c9053ae5d90f8ac929d 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 threaded The current behaviour surely isn't introduced as explicit design choice, more an side-effect of a commit. The result is undesired in my opinion. As described by Thomas in comment 11 and comment 13.
The ticket was in state NEEDINFO for too long and got resolved INSUFFICIENTDATA therefore. If you reopen please reply to JBF's comment 19 first.
Created attachment 183997 [details] Simplified document (In reply to Heiko Tietze from comment #23) > The ticket was in state NEEDINFO for too long and got resolved > INSUFFICIENTDATA therefore. If you reopen please reply to JBF's comment 19 > first. (In reply to Jean-Baptiste Faure from comment #19) > 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. JB I'm not really sure how to respond to this.. Why do I want to get back to the cursor? The opposite happens, I make a change, I lose the page in view. Which one was it? I can't even tell if the desired result achieved. 1. Open the attached file 2. Cursor at the page 1 (default) 3. Scroll to page 3, hoover over the page break 4. Click Edit Page Break -> Text flow tab -> Select with page style -> Landscape 5. Press OK Result: Document scrolls to top. I question myself: Did the change occur? Or was there some error and I'm bouncing back to page 1? Expected: Don't scroll to page 1, but keep at - in this case - page 3. I could argu that the cursor should move change to page 3, when clicking the 'blue header button, edit page break' button. It's technically a paragraph property of the page in question. I see two solutions. A simply view lock, or moving the cursor when opening the paragraph properties dialog using the blue bar.