Bug 72072

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