Download it now!
Bug 134439 - Page Break: editing "Text flow > Breaks" gives differing results depending on where the cursor is situated
Summary: Page Break: editing "Text flow > Breaks" gives differing results depending on...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: high major
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.1.0 target:6.4.7 target:7.0.2
Keywords: bibisected, bisected, needUITest, regression
: 132600 (view as bug list)
Depends on:
Blocks: Writer-Page-Break
  Show dependency treegraph
 
Reported: 2020-07-01 16:13 UTC by R. Green
Modified: 2020-08-31 10:27 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Writer file showing bug in page break editing (19.37 KB, application/vnd.oasis.opendocument.text)
2020-07-01 16:13 UTC, R. Green
Details

Note You need to log in before you can comment on or make changes to this bug.
Description R. Green 2020-07-01 16:13:24 UTC
Created attachment 162564 [details]
Writer file showing bug in page break editing

Version: 6.4.4.2 (x64)
Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win; 
Locale: en-GB (en_GB); UI-Language: en-GB
Calc: threaded

1. Open the attached file.
2. Hover over the page break (blue dotted line) between pages 1 and 2. Click on it and select "Edit Page Break."
3. Go to the "Text Flow" tab, change the Page style to "Page 3", and OK.

EXPECTED RESULT: P2 should assume the page style of "Chap 3."
ACTUAL RESULT: P2 page style is unchanged but P1 assumes style of "Chap 3".

4. Close the file without saving and reopen. Repeat the above but choose a different page break.

ACTUAL RESULT: the P1 page style changes in error each time.

5. Now close the the file without saving and reopen.
6. Click on P2 and change the page style to "Chap 3".
7. Hover over the page break (blue dotted line) between pages 1 and 2. Click on it and select "Edit Page Break."
8. Go to the "Text Flow" tab, change the Page style to "Page 2", and OK.

EXPECTED/ACTUAL RESULT: P2 page style changes to "Chap 2" and P1 remains unchanged.
Comment 1 Heiko Tietze 2020-07-02 10:11:21 UTC
In what form is this ticket different to bug 134395?
Comment 2 R. Green 2020-07-02 11:27:30 UTC
(In reply to Heiko Tietze from comment #1)
> In what form is this ticket different to bug 134395?
In Bug 134395 I did not know that page breaks are indicated by dotted lines between pages, nor was I aware of a "Edit Page Break" dialogue (nothing in the help files?): so it wasn't specific enough. Having now discovered the "Edit Page Break" dialogue, the above bug report makes good the deficiencies in the original.
Comment 3 R. Green 2020-07-03 11:27:44 UTC
The root of the problem is that the result depends on where the cursor is initially situated.

CURSOR AT END OF HEADING:

Try this:

1. Open the file and make sure that you do not click anywhere with a mouse. The cursor defaults to the end of "Chapter 1".
2. Now repeat steps 2-3 (in the opening post).

EXPECTED RESULT: P2 should assume the page style of "Chap 3."
ACTUAL RESULT: P2 page style is unchanged but P1 assumes style of "Chap 3".

CURSOR IN PAGE 1 TEXT

Try this:

1. Open the file and click somwhere in the text body of page 1.
2. Now repeat steps 2-3 (in the opening post).

EXPECTED RESULT: P2 should assume the page style of "Chap 3."
ACTUAL RESULT: A page break is inserted between the chapter heading and the text body of page 1. P2 should assume the page style of "Chap 3."

CURSOR IN PAGE 2 TEXT

Try this:

1. Open the file and click somwhere in the text body of page 2.
2. Now repeat steps 2-3 (in the opening post).

EXPECTED/ACTUAL RESULT: P2 assumes the page style of "Chap 3."

--------------------------------------------------

SUGGESTION: Make sure that "Edit page break" is independent of the cursor location.
Comment 4 Telesto 2020-07-03 11:34:38 UTC
(In reply to R. Green from comment #3)
> The root of the problem is that the result depends on where the cursor is
> initially situated.
> 
> CURSOR AT END OF HEADING:
> 
> Try this:
> 
> 1. Open the file and make sure that you do not click anywhere with a mouse.
> The cursor defaults to the end of "Chapter 1".
> 2. Now repeat steps 2-3 (in the opening post).
> 
> EXPECTED RESULT: P2 should assume the page style of "Chap 3."
> ACTUAL RESULT: P2 page style is unchanged but P1 assumes style of "Chap 3".
> 
> CURSOR IN PAGE 1 TEXT
> 
> Try this:
> 
> 1. Open the file and click somwhere in the text body of page 1.
> 2. Now repeat steps 2-3 (in the opening post).
> 
> EXPECTED RESULT: P2 should assume the page style of "Chap 3."
> ACTUAL RESULT: A page break is inserted between the chapter heading and the
> text body of page 1. P2 should assume the page style of "Chap 3."
> 
> CURSOR IN PAGE 2 TEXT
> 
> Try this:
> 
> 1. Open the file and click somwhere in the text body of page 2.
> 2. Now repeat steps 2-3 (in the opening post).
> 
> EXPECTED/ACTUAL RESULT: P2 assumes the page style of "Chap 3."
> 
> --------------------------------------------------
> 
> SUGGESTION: Make sure that "Edit page break" is independent of the cursor
> location.

Confirm
Version: 7.1.0.0.alpha0+ (x64)
Build ID: c48e4d795e37f23b71d647247590807ab9e52223
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 5 Telesto 2020-07-03 11:37:39 UTC
Working properly with
Version: 6.0.5.0.0+
Build ID: 15ea1cda0b3c37ff944ad9a239b7ed453e8b0591
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 6 Telesto 2020-07-03 16:52:59 UTC
@Buovjaga
A QA team members in training bibisect?
Comment 7 Buovjaga 2020-07-04 11:35:58 UTC
(In reply to Telesto from comment #6)
> @Buovjaga
> A QA team members in training bibisect?

Thanks, this is indeed a good one because it happens in the same repo that is used for the bibisecting tutorial.

The bibisecting of this report is reserved for new QA team members in training. Bibisecting should be done using the win32-6.1 repo.
Comment 8 Telesto 2020-07-30 21:00:51 UTC
(In reply to Buovjaga from comment #7)
> (In reply to Telesto from comment #6)
> > @Buovjaga
> > A QA team members in training bibisect?
> 
> Thanks, this is indeed a good one because it happens in the same repo that
> is used for the bibisecting tutorial.
> 
> The bibisecting of this report is reserved for new QA team members in
> training. Bibisecting should be done using the win32-6.1 repo.

Not funny to bibisect.. probably point has to bibisect where the crashing stopped instead of the flaw itself. First impression: a cursor crash issue
Comment 9 Telesto 2020-08-10 18:38:59 UTC
The crashing stopped, and the wrong behavior got visible after
author	Jan Holesovsky <kendy@collabora.com>	2018-03-01 21:00:24 +0100
committer	Jan Holesovsky <kendy@collabora.com>	2018-03-02 09:27:02 +0100
commit	bba8e5aa6d1968e5279b3fe368c0f81145513d04 (patch)
tree	6719d0ce1a471ac3e2963ca4e2b9ce5ac2f28009
parent	477d2ba662cbd716588519419eece2b4f06d8610 (diff)
tdf#116070: Use a valid PaM when confirming the dialog.
Change-Id: I8d45e709e6414814b3cf04bbd09588ab4e096e8c
Reviewed-on: https://gerrit.libreoffice.org/50598
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Comment 10 Telesto 2020-08-10 18:45:53 UTC
The behavior was good until the crashing started. The crashing started with
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
Reviewed-on: https://gerrit.libreoffice.org/48011
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
Comment 11 Telesto 2020-08-10 18:48:27 UTC
@Jan Holesovsky
Any idea if you're commits could be related to this..
Comment 12 Telesto 2020-08-11 12:59:02 UTC
Increasing priority as bug 135636 is caused by the same issue
Comment 13 Xisco Faulí 2020-08-13 13:27:36 UTC
(In reply to Telesto from comment #10)
> The behavior was good until the crashing started. The crashing started with
> 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
> Reviewed-on: https://gerrit.libreoffice.org/48011
> Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
> Tested-by: Jenkins <ci@libreoffice.org>

I do really believe the mentioned commit introduced this issue

@Caolán, I thought you might be interested in this issue since it's one of those introduced by making the dialog async
Comment 14 Commit Notification 2020-08-16 19:15:44 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/d04c64d25929f08f9991535ecc8a33bdd31d395e

tdf#134439 honor FN_PARAM_PAM arguments

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Caolán McNamara 2020-08-16 19:16:11 UTC
fixed in master, backports to 7-0 and 6-4 in gerrit
Comment 16 Commit Notification 2020-08-17 09:43:49 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/88aa305d2fdb76b8cf1bcd589c698ae5167796e1

tdf#134439 honor FN_PARAM_PAM arguments

It will be available in 6.4.7.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Commit Notification 2020-08-17 09:44:03 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/9818f70897ffff9098b315eed7c6e4e19bc81ceb

tdf#134439 honor FN_PARAM_PAM arguments

It will be available in 7.0.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Telesto 2020-08-22 21:13:10 UTC
*** Bug 132600 has been marked as a duplicate of this bug. ***
Comment 19 Telesto 2020-08-30 13:51:16 UTC
@Caolan
Want to bring a Kohei presentation to mind. Especially sheet 26 https://www.slideshare.net/kohei101/life-after-calc-core-change

The whole approach is currently annoying frustrating, straining, tiresome..

1) From user perspective quality wise; brokenness not great 
2) From user perspective, reporting bugs and bugs over in over in the same area. (I assume mwtjunkmail can vouch for that)
3) From QA perspective, having to confirm/bibisect those bugs 
4) From developer perspective, being hunted by those fall out after the fact

Not the only one I'm asking/ begging to do this more often. See bug 134213 comment 57

They unit test should be voluntary, but mandatory. So or a unit test or some good explanation why it's lacking. Happy with few default boilerplate text exceptions. .. but the consideration should be by default. 

They boilerplate can be used for in the sense of 'we told you so'.. The mentally/culture around unit tests (of whatever you want to call those)at dev department needs shift.. 

I only know Justin L. doing this consequently from my perspective (of course different area of expertise with different types of testing). But a bug as this one can be tested. Instead of drifting around for 2 years, and causing quite some flabbergasted/ surprised faces 

R. Green needed already few runs until he figured out this one. And I guess some people should have encountered it before (except it didn't land here). 

FWIW it's more a 'general' advise, not specially directed to you in person.
Comment 20 Caolán McNamara 2020-08-31 08:12:58 UTC
be the change you want it to be