Created attachment 66445 [details]
document to reproduce the bug case

did not happen in OOo 3.1.1 => regression

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?

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.

putting MRU on CC

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..

I also reproduced the described defect under Solaris Sparc and Linux with OOo 3.1.1

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.

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.

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.

Created attachment 66448 [details]
suggested patch

> 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 ...

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.

Created attachment 66466 [details]
suggested patch applied in Writer's direct paint method

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.

AW->OD: The patch looks good for me and would be pretty safe for 3.2 if really
needed.

adjusted target

add issue to cws sw32bf09 - patch will be applied as soon as the cws is ready.

decided to apply patch to CWS ooo32gsl09

fixed in cws ooo32gsl09 - changed file:
/sw/source/core/view/viewsh.cxx, rev. 277743

OD->SBA: Checked in internal installation set of cws ooo32gsl09 - please verify.

Verified in CWS ooo32gsl09.

Checked w/ OOO320_RC1, Ubuntu 9.1

Closing