Description: LibreOffice ignores page break when adding a table to the second page Steps to Reproduce: 1. Open Writer 2. Insert a page break -> CTRL+ENTER 3. Insert a table on the second page -> Second page disappears; table moves to the first 4. Second attempt: Insert some text on the first page. Press CTRL+ENTER.. Try to add a table to the second page. Table will be at the first page Actual Results: Table the the first page Expected Results: Table should be added to the second page Reproducible: Always User Profile Reset: No Additional Info: Found in Versie: 6.0.0.2 Build ID: 06b618bb6f431d27fd2def25aa19c833e29b61cd CPU-threads: 4; Besturingssysteem: Windows 6.3; UI-render: GL; Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 139115 [details] Bibisect log Bisected to: author Jim Raykowski <raykowj@gmail.com> 2017-10-31 15:48:07 -0800 committer Yousuf Philips <philipz85@hotmail.com> 2017-12-27 15:27:50 +0100 commit 203b913155812706e9be14c5fe2b8f543cc4fdc7 (patch) tree e2233e80cbc67d0bf834d4eb716ff935cebe6d08 parent 023949fac0043408ac1b86dc67732666d041875e (diff) tdf#107555 Apply 'Default Style' table style to newly inserted tables
@Jay, Thought you might be interested in this one
Hi Telesto, I confirm with LO 6.0.0.2 Build ID: 06b618bb6f431d27fd2def25aa19c833e29b61cd Threads CPU : 2; OS : Windows 6.1; UI Render : par défaut; Locale : fr-FR (fr_FR); Calc: CL Worked as excepted with LO 6.0.0.1 (x64) Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a Threads CPU : 2; OS : Windows 6.1; UI Render : par défaut; Locale : fr-FR (fr_FR); Calc: CL
@Jim, Seems your apply default table style to inserted table patch has a regression. https://gerrit.libreoffice.org/#/c/46842/
(In reply to Yousuf Philips (jay) from comment #4) > @Jim, > Seems your apply default table style to inserted table patch has a > regression. > > https://gerrit.libreoffice.org/#/c/46842/ Hi Jay, This behavior can be reproduced in versions before the patch was merged by manually performing what the patch does automatically. (Apply a style to a table) I have reproduced it in the following two versions: Version: 5.4.4.2, Build ID: 1:5.4.4~rc2-0ubuntu0.16.04.1~lo1 and Version: 6.0.0.0.beta2 (x64) mswindows Here are the steps to reproduce in pre patched versions: 1. Open a version of Writer without this patch 2. Open Sidebar -> View > Sidebar 3. Click on Styles deck icon 4. Click on Tables Styles icon in Styles Panel 5. Insert a page break -> CTRL+ENTER 6. Insert a table on the second page 7. Double click on any table style in the list box in the Styles Panel Actual Results: Table moves to previous page Expected Results: Table should stay on page it was on
Found in Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89) but not in LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5 1. Open Writer 2. Insert a page break (CTRL+ENTER) 3. Add a table on the next page 4. Menu Table -> Autoformat styles -> Choose a style and apply Table moves to previous page
Created attachment 139143 [details] Bibisect log I would suspect the patch for bug 49342...
Confirm the behavior from Comment 6 with LO 3.6.0.4 (Build ID: 932b512) and upper versions but not with LO 3.5.7.2 Version ID : 3215f89-f603614-ab984f2-7348103-1225a5b under Windows 7 Home.
I have located what seems to be the cause of this bug. tblafmt.cxx void SwTableAutoFormat::RestoreTableProperties(SwTable &table) const { SwTableFormat* pFormat = table.GetFrameFormat(); if (!pFormat) return; SwDoc *pDoc = pFormat->GetDoc(); if (!pDoc) return; SfxItemSet rSet(pDoc->GetAttrPool(), aTableSetRange); // rSet.Put(m_aBreak); <<<<< comment this line When this line of code is removed a table inserted at the start of a new page behaves as expected. I don't really understand why. My knowledge of itemsets and pools and ranges is not strong.
Created attachment 139232 [details] commit that introduce Break table-level property recording Here may be where this behavior began.
Repro with: Version: 6.1.0.0.alpha0+ Build ID: 2ed7c02478968852d7d39c2c4677f2ecf3441bc7 CPU threads: 4; OS: Windows 6.3; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2018-04-22_01:00:56 Locale: nl-NL (nl_NL); Calc: CL
Repro Version: 6.2.0.0.alpha0+ Build ID: 8e9d43546c8e46ea635472ddf07f5c183dc13360 CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-07-11_23:34:15 Locale: nl-NL (nl_NL.UTF-8); Calc: group threaded STR 1. Open Writer 2. Insert a page break -> CTRL+ENTER 3. Insert a table with a table style applied (non-default)
This is related to the table properties text flow: Table > Properties... > Text Flow tab > Break checkbox and break type radio buttons. One way we can can work around this case is by not setting the break here [1] if it is SvxBreak::NONE. [1] https://opengrok.libreoffice.org/xref/core/sw/source/core/doc/tblafmt.cxx#906
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to Jim Raykowski from comment #13) > One way we can can work around this case is by not setting the break here > [1] if it is SvxBreak::NONE. Exactly. https://gerrit.libreoffice.org/#/c/83879
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/43f983d08d66520536980339f33ef44d5eec35f6 tdf#115026 sw tableAutoFormat: don't clear break/keep It will be available in 6.5.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.
(In reply to Telesto from comment #12) > Repro > Version: 6.2.0.0.alpha0+ > Build ID: 8e9d43546c8e46ea635472ddf07f5c183dc13360 > CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; > TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-07-11_23:34:15 > Locale: nl-NL (nl_NL.UTF-8); Calc: group threaded > > STR > 1. Open Writer > 2. Insert a page break -> CTRL+ENTER > 3. Insert a table with a table style applied (non-default) Issue verified in Version: 6.5.0.0.alpha0+ Build ID: 838935758a5ec8e0e68f4df0cf5bfcf737e3f6f2 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Justin, thanks for fixing this issue!!
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/a1ed3efdac81c7f23616d0a3a32b34876923b448 tdf#115026 sw tableAutoFormat: don't clear break/keep It will be available in 6.4.1. 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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/43d8dc34d74832e928c2cc215e9bf512f4edf3b3 tdf#115026: Add uitest It will be available in 6.5.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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/822bbe6984a642ea3c09ca8a337499655cd54173 tdf#115026: Add uitest It will be available in 6.4.1. 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.