Created attachment 116106 [details] Adding text above a textsection Win 8.1, 64 Bit, LibO 5.0.0.0.beta1 64 Bit creating or reworking a writer document with a textsection (see picture): - first paragraphs normal text... - followes by a textsection with two colums -> everything is ok. Getting back to the text above the textsection and add some more text and/or paragraphs: Textsection will stay at position, new text will overlay old text... see screenshot. Problem seems to be a redraw/timing problem. If focus is set to outside LibO and then come back, document shows correct content - textsection has been moved.
I am setting status NEW and adding keyword "regression" I see the reported problem on debian-wheezy in dbgutil version 2015-05-28 ... Version: 5.1.0.0.alpha1+ Build ID: be01d68420086fc36ecf26b5f597ba7c6b29b369 Locale: en-CA (en_CA.UTF-8) and on Vista in recent Windows daily ... Version: 5.1.0.0.alpha1+ Build ID: 487880b6882ec01c1b4679eae60bec484272a86b TinderBox: Win-x86@39, Branch:master, Time: 2015-05-28_04:59:56 Locale: en-CA (en_CA) but not on debian-wheezy in version 3.5.4.2. As shortcut toward demonstrating the problem, (1) download and open attached example.odt. (2) Position cursor after the text "So type more text here". (3) Type text beyond the end of the line. Observe that your new text overlays the text section. Note that the problem is the same if the text section has only one column. If you save, close, and open the file, the problem is corrected. HTH, Terry.
I am changing the summary from "Writer: Problems with textsections - no redraw" to " It seems that this bug came into Liberoffice between 2014-12-03 ... Version: 4.4.0.0.alpha2+ Build ID: 2b5b04e1e62914bf0902dfd7943cdc44499c47a6 Locale: en_CA and 2015-05-20 ... Version: 5.0.0.0.alpha1+ Build ID: 90e2dabb8d0bb5382234be776c2ad0e2d5d9e224 Locale: en-CA (en_CA.UTF-8) I notice that there are less drastic ways to make LibreOffice fix the rendering: (a) Passage of time as I did various things, like writing comment 1. (b) Changing text so far down the document (and outside the textsection, as it happen) while the bad rendering is off the top of the editing area.
I've seen similar problems with TOC, where the heading flow in the TOC after iirc an update of the TOC. The problem went away after saving and opening.
Working in the 50all bibisect repository, I see from `git bisect good` ... e990d63f8e9c24bae77ce04c10790e23fdcf63fc is the first bad commit commit e990d63f8e9c24bae77ce04c10790e23fdcf63fc Author: Matthew Francis <mjay.francis@gmail.com> Date: Wed May 27 21:00:43 2015 +0800 source-hash-9857c6390212e16dd9f26b47b4afc5d33b5242ef commit 9857c6390212e16dd9f26b47b4afc5d33b5242ef Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Tue Mar 31 17:14:19 2015 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Tue Mar 31 17:54:09 2015 +0100 crashtest: crash on layout of novell622972-2.html Change-Id: I49be59a9b9cdda8f80b6579f393be0a99f231833 :040000 040000 d59539d18767bcf1ac14847fb91b716ba695d223 2ea31552a63c96968c5777d3bef2ff1ba9ce2690 M opt and from `git bisect log` ... # bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e] source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86 # good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091] source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311 git bisect start 'latest' 'oldest' # good: [0c30a2c797b249d0cd804cb71554946e2276b557] source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d git bisect good 0c30a2c797b249d0cd804cb71554946e2276b557 # bad: [2ce02b2ce56f12b9fcb9efbd380596975a3a5686] source-hash-17d714eef491bda2512ba8012e5b3067ca19a5be git bisect bad 2ce02b2ce56f12b9fcb9efbd380596975a3a5686 # good: [e4deb8a42948865b7b23d447c1547033cb54535b] source-hash-ce46c98dbeb3364684843daa5b269c74fce2af64 git bisect good e4deb8a42948865b7b23d447c1547033cb54535b # good: [30a39c6a9e3c59d493447b25aaeb1f70f194bbd7] source-hash-be44ec8c28ce2af9644fcc58317dc1c9b20e2a21 git bisect good 30a39c6a9e3c59d493447b25aaeb1f70f194bbd7 # bad: [1a8cb86ddf494004e5f68b16c1a4e7535a97a880] source-hash-4d48b51ad4481a3e2ed8bc79728d1c845f58aed6 git bisect bad 1a8cb86ddf494004e5f68b16c1a4e7535a97a880 # bad: [b2db83e20d8df9c271af0477bbdd14105474d187] source-hash-3cae8ee10f297e42adf9f3b33809b4e7e3af2840 git bisect bad b2db83e20d8df9c271af0477bbdd14105474d187 # bad: [fd6692018bac8b561855ab89920195648fb2fc7c] source-hash-e4c1c0829a44a5992efa35a8445cb3448dc10960 git bisect bad fd6692018bac8b561855ab89920195648fb2fc7c # bad: [7b44ff06931b92d90f522453eb5790b13bd1ca20] source-hash-d1e63af0fb5c9aa344baae0c34d069385b8f0736 git bisect bad 7b44ff06931b92d90f522453eb5790b13bd1ca20 # good: [79d3070f1d1b91b00a14ead638c1941bb040136a] source-hash-b89681bef2e492bccb9502079e042ff495b40c39 git bisect good 79d3070f1d1b91b00a14ead638c1941bb040136a # skip: [5de973f06ff1d34eb4ede3d4b2de8cb43541a0b3] source-hash-b9301e9dc93f5961bd83a76410f91174316c99b3 git bisect skip 5de973f06ff1d34eb4ede3d4b2de8cb43541a0b3 # good: [2339af1f24950353e6fdc0bd6457b887a1a36ae7] source-hash-e27d7c38ba1de0f4bbb1197bd84c063a0fdee9d1 git bisect good 2339af1f24950353e6fdc0bd6457b887a1a36ae7 # bad: [c09648367765f358644560a20a6827b644e14e9b] source-hash-109717c9a2a4d33f2210ed1fbf6d874ff04f32d3 git bisect bad c09648367765f358644560a20a6827b644e14e9b # bad: [309034ecf7f16c448e3be2f153712039cf96458c] source-hash-56c003b4f3b3ed77dc6608584fd50fbda901d1b4 git bisect bad 309034ecf7f16c448e3be2f153712039cf96458c # bad: [e990d63f8e9c24bae77ce04c10790e23fdcf63fc] source-hash-9857c6390212e16dd9f26b47b4afc5d33b5242ef git bisect bad e990d63f8e9c24bae77ce04c10790e23fdcf63fc # good: [46e5fbd7ee13dcd3e10977a40fbf6fc47778128f] source-hash-debf3ffb87d607704ddea97f6710c3ceaa9a243d git bisect good 46e5fbd7ee13dcd3e10977a40fbf6fc47778128f # first bad commit: [e990d63f8e9c24bae77ce04c10790e23fdcf63fc] source-hash-9857c6390212e16dd9f26b47b4afc5d33b5242ef
Of course, I meant in comment 4 to say that I was working in the 50max bibisect repository.
bibisect with 50max repository warrants keyword "bisected".
Created attachment 116397 [details] Test file
Test file attached. Type some text after the bold text to check the problem. @Caolán, could you check this bug introduced by the commit 9857c6390212e16dd9f26b47b4afc5d33b5242ef? Thanks in advance!
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=64dc505ce180a168798b725423a308207de42c63&h=libreoffice-5-0 Resolves: tdf#91695 partially Revert "crash on layout of novell622972-2.html" It will be available in 5.0.0.0.beta3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://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 "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dfedebd1e1912252bc2b5204a2b5371952b552cd Resolves: tdf#91695 partially Revert "crash on layout of novell622972-2.html" It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I reverted the part of the original commit which caused that
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]