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.
In what form is this ticket different to bug 134395?
(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.
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.
(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
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
@Buovjaga A QA team members in training bibisect?
(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.
(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
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>
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>
@Jan Holesovsky Any idea if you're commits could be related to this..
Increasing priority as bug 135636 is caused by the same issue
(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
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.
fixed in master, backports to 7-0 and 6-4 in gerrit
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.
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.
*** Bug 132600 has been marked as a duplicate of this bug. ***
@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.
be the change you want it to be
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d4a96a931210fc4713d4ab6325e30cd34ffa7b37 tdf#134439, tdf#116070: sw: Add UItest It will be available in 7.2.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.