Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||form control preceeding paragraph text vanishes when text is edited|
|Product:||Writer||Reporter:||Frank Schönheit <frank.schoenheit>|
|Status:||CLOSED FIXED||QA Contact:||issues@sw <issues>|
|Priority:||P3||CC:||Armin.Le.Grand, cno, issues, michael.ruess, philipp.lohmann|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
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
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