Created attachment 89900 [details] Picture of the bug in Writer and Draw Hi Steps to reproduce: 1) - Draw a rectangle and fill some Text in it (The error is in Writer and Draw) 2) - Turn the rectangle by 90 deg 3) - Edit the Text -> the Text disapear partwise (see Picture) 4) - Resize the brogramm window a bit -> the Text will appear as expected System: -Windows 7 -Libreoffice 4.2.0.0 beta and -LibreOffice 4.1.3 Thanks Ralf
Created attachment 89901 [details] Picture of the bug in Writer and Draw
Created attachment 89926 [details] Bug-confirmed-on-Ubuntu-13-04.png Tested this bug on Ubuntu 13.04 with LO 4.2Beta1. I can confirm this bug. Please see attached screenshot.
CONFIRMED on LO 4.2.0.0.beta2 + Ubuntu 12.04.3 (In reply to comment #0) > Steps to reproduce: 0) Open LibreOffice writer > 1) > - Draw a rectangle and fill some Text in it (The error is in Writer and Draw) (Hint: double-click on the rectangle to add text) > 2) > - Turn the rectangle by 90 deg a) Right-click -> Position and Size -> Rotation b) Change 'Rotation angle' to 90deg. c) Click "OK" > 3) > - Edit the Text -> the Text disapear partwise (see Picture) a) Double-click on rectangle b) Add text that is wider than the dimensions of the text box c) Hit 'Return' to save While editing the text I'd often get a white bg behind the text area. I could always repro the problem if I - did all of the steps above - Then double-clicked on the text again Basically: The text needs to be wider than the width of the rectangle at the time when you double-click on it. > 4) > - Resize the brogramm window a bit -> the Text will appear as expected > Ayup Question: is this a regression?
I think it is a regression. It worked without problems here on LO 4.0.6.2 / Win7.
Writer bug: a40afb3f534ea1c655ac728e55a7e4b96b033869..2f4eeea1730e2931249471eddc203b13a6ac4ed4 regression from: commit a2c67975c03010b90c706523293f180c1f29e229 Author: Michael Stahl <mstahl@redhat.com> AuthorDate: Wed Aug 28 14:28:40 2013 +0200 fdo#67358: sw: "fix" line painting artifacts when resizing columns SwEditWin::MouseButtonDown(): for unknown reasons invalidating the window here causes the column resizing lines to not be removed after the resize is done, so disable it. ... oh noes. the Draw bug actually has a different cause, the above commit only affects Writer.
have filed bug 73668 about the Draw problem - which may or may not have the same root cause. regression in 4.1.2 release.
(This is an automated message.) Setting priority to highest as this is a 4.2 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
I'm not reproducing this bug with 4.3.2.2 can anyone retest to see if it's really fixed?
(This is an automated message.) It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.) Thus setting keyword "bisected".
gotcha!!! the bug depends on the size of the LibO window while you edit. I'm not able to reproduce it when LibO is in full window state, however if I modify the window size while editing I see the partial disappearance of the text. so still present in 4.3.4.1 and 4.5.0.0 alpha mopving to mab4.3 list since 4.2.x is END OF LIFE
Created attachment 117053 [details] testfile. just double click on the rectangle still reproducible under Win8.1 x64 using LibO 4.4.3.2 and 5.1.0.0.alpha1+ (x64) Build ID: 67afab2a7cd5596d321bb85e6e2624df19c2296b TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-07-04_22:51:13 Locale: en-US (it_IT) uplaoded simple test case to make easier and faster to reproduce the issue
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Adding Cc: to Michael Stahl
No problem in Version: 6.2.0.0.alpha0+ (x64) Build ID: f7f2d03bd6f5aa5dcd0f7976b4a7f2db278c2f03 CPU threads: 8; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-25_05:00:28 Locale: de-DE (de_DE); Calc: CL I see no dependency to window size. I have tested while OpenGL was disabled.
Appears fixed meanwhile, as Regina mentioned (tested in 6.1.3, Linux).