Issue 107365

Summary: form control preceeding paragraph text vanishes when text is edited
Product: Writer Reporter: Frank Schönheit <frank.schoenheit>
Component: uiAssignee: stefan.baltzer
Status: CLOSED FIXED QA Contact: issues@sw <issues>
Severity: Trivial    
Priority: P3 CC: Armin.Le.Grand, cno, issues, michael.ruess, philipp.lohmann
Version: OOO320m6Keywords: regression
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 99999    
Attachments:
Description Flags
document to reproduce the bug case
none
suggested patch
none
suggested patch applied in Writer's direct paint method none

Description Frank Schönheit 2009-12-01 22:11:47 UTC
- open the attached text document
- position the cursor with the first word "Change"
- type some text
=> the control at the beginning of the text vanishes

Forcing a repaint of the document by any means brings back the control.

Happens only if the control is in alive mode. Does not happen for
non-transparent controls.
Comment 1 Frank Schönheit 2009-12-01 22:12:40 UTC
Created attachment 66445 [details]
document to reproduce the bug case
Comment 2 Frank Schönheit 2009-12-01 22:16:45 UTC
did not happen in OOo 3.1.1 => regression
Comment 3 Frank Schönheit 2009-12-01 22:19:47 UTC
fs->aw: The "VCL hack for transparent child windows"
OverlayManagerBuffered::ImpBufferTimerHandler is already integrated into m6,
still, we seem to have more problems with transparent VCL child windows here.
Any idea?
Comment 4 Oliver-Rainer Wittmann 2009-12-02 08:29:49 UTC
I have reproduced the described defect on my system (Windows) with OOo 3.1.1 and
OOo 3.1.
Thus, we need at least one more test to find out in which version the
functionality is broken.
Comment 5 Oliver-Rainer Wittmann 2009-12-02 08:42:06 UTC
putting MRU on CC
Comment 6 cno 2009-12-02 08:50:12 UTC
I could not reproduce the problem in 3.1.1 yesterday (late in the evening ;-) )
on WinXP and Debian.

But now, when I edit close to the start of the line, the problem does show.

The controls do not disappear when I change the text further from the start of
the line.
Maybe this helps finding the root..
Comment 7 Oliver-Rainer Wittmann 2009-12-02 08:52:58 UTC
I also reproduced the described defect under Solaris Sparc and Linux with OOo 3.1.1
Comment 8 Frank Schönheit 2009-12-02 08:53:31 UTC
Interesting, I am not able to reproduce this in 3.1.1, no matter what.

Not sure if this means the issue doesn't qualify as 3.2 anymore (I'd like to
discuss the 3,2 target as soon as we know more about the issue's cause and
possible fix). For once, it is not strictly a regression since 3.1.1, on the
other hand, it seems it is easier to encounter now.
Comment 9 michael.ruess 2009-12-02 09:12:16 UTC
I can confirm Cor's experience - the issue occurs slightly different in 3.2 than
in 3.1.1. In 3.1.1 I had to enter text right at the beginning or following the
"C" in that para to trigger the bug. In 3.2 I can enter text anywhere in the
first two words to trigger the effect.
Comment 10 Frank Schönheit 2009-12-02 09:48:08 UTC
fs->aw: Debugging this shows that the control's area is erased from within
SdrPreRenderDevice::OutputPreRenderDevice. If I add, therein, code to invalidate
transparent child windows (taken from
OverlayManagerBuffered::ImpBufferTimerHandler), then the bug vanishes.

I'll attach the patch for this, but only you can judge whether this is a
legitimate approach, and possible correct it, so please take over the issue.
Comment 11 Frank Schönheit 2009-12-02 09:48:46 UTC
Created attachment 66448 [details]
suggested patch
Comment 12 Frank Schönheit 2009-12-02 09:54:16 UTC
> In 3.1.1 I had to enter text right at the beginning or following the
> "C" in that para to trigger the bug

Ah! - with that, I can reproduce it in 3.1.1, too ...
Comment 13 Armin Le Grand 2009-12-02 14:29:38 UTC
AW: Problem is isolated. When painting to a VCL-Window outside a regular
VCL-Repaint, transparent ChildWindows are painted over and everyone doing so has
to take care himself that those windows get refreshed. VCL is informed and
thinking about a mechanism to automatise this.
This means that the line refresh in SW paints directly to Window and (as overlay
does) has to refresh the transparent ChildWindows after the paint is done. Since
the paint uses the DrawingLayer repaint mechanism, the patch as proposed works.
It is not the best solution, because it will also be triggered insinde a regular
VCL-Repaint. It would be better to add that functionality directly at the spot
in SW where that direct paint is executed (at it's end).

Thus i propose that FS or OD add the needed code there or wait until VCL offers
a method (as a compromize) at the VclWindow which may be something like
'TakeCareForTransparentChildWindows(Region)'.

AW->OD: I think You are the most qualified to isolate the spot in SW where this
would need to be done.
Added PL to CC, too.
Comment 14 Oliver-Rainer Wittmann 2009-12-03 09:14:07 UTC
Created attachment 66466 [details]
suggested patch applied in Writer's direct paint method
Comment 15 Oliver-Rainer Wittmann 2009-12-03 09:16:18 UTC
OD->AW:
Please have a look at the new patch, which I have applied in the Writer's direct
paint method.
If it is ok, we may ask for nomination of this issue for target OOo 3.2
Thanks in advance.
Comment 16 Armin Le Grand 2009-12-03 14:19:03 UTC
AW->OD: The patch looks good for me and would be pretty safe for 3.2 if really
needed.
Comment 17 uwe.luebbers 2009-12-04 12:18:54 UTC
adjusted target
Comment 18 Oliver-Rainer Wittmann 2009-12-04 12:31:42 UTC
add issue to cws sw32bf09 - patch will be applied as soon as the cws is ready.
Comment 19 Oliver-Rainer Wittmann 2009-12-04 13:29:46 UTC
decided to apply patch to CWS ooo32gsl09
Comment 20 Oliver-Rainer Wittmann 2009-12-07 14:05:48 UTC
fixed in cws ooo32gsl09 - changed file:
/sw/source/core/view/viewsh.cxx, rev. 277743
Comment 21 Oliver-Rainer Wittmann 2009-12-08 10:11:24 UTC
OD->SBA: Checked in internal installation set of cws ooo32gsl09 - please verify.
Comment 22 stefan.baltzer 2009-12-10 09:18:20 UTC
Verified in CWS ooo32gsl09.
Comment 23 drewjensen.inbox 2010-01-10 17:54:07 UTC
Checked w/ OOO320_RC1, Ubuntu 9.1

Closing