Issue 105880 - Selection background in writer not visible when transparent graphics in view area
Summary: Selection background in writer not visible when transparent graphics in view ...
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: DEV300m60
Hardware: All Unix, all
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: stefan.baltzer
QA Contact: issues@gsl
Keywords: accessibility, oooqa, regression
: 105843 (view as issue list)
Depends on:
Blocks: 99999
  Show dependency tree
Reported: 2009-10-13 20:20 UTC by andreschnabel
Modified: 2009-12-01 07:46 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

brocken selection background (79.59 KB, image/png)
2009-10-13 20:23 UTC, andreschnabel
no flags Details
selection background ok (113.21 KB, image/png)
2009-10-13 20:24 UTC, andreschnabel
no flags Details
select some text, then zoom the view (15.18 KB, application/vnd.oasis.opendocument.text)
2009-10-21 17:52 UTC, andreschnabel
no flags Details
same example with embedded graphic (16.28 KB, application/vnd.oasis.opendocument.text)
2009-10-21 18:25 UTC, andreschnabel
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description andreschnabel 2009-10-13 20:20:45 UTC
In some cases, the selection in the help browser will have no visible
background. This happens only on Linux (unix) and if images are displayed.Plain
text pages are ok.

To reproduce:
- make sure transparent selection is enabled
- open OOo help
- use index to open "3D Objects; assembling"
- select some text at the help page

-> you'll only see the selection border, but no background

You may also try the same with a plain text page (e.g. index "accents").
-> selection background displays correctly

worked in OOo 3.1.1
Comment 1 andreschnabel 2009-10-13 20:23:41 UTC
Created attachment 65348 [details]
brocken selection background
Comment 2 andreschnabel 2009-10-13 20:24:33 UTC
Created attachment 65349 [details]
selection background ok
Comment 3 Olaf Felka 2009-10-14 06:43:00 UTC
Comment 4 Uwe Fischer 2009-10-14 09:32:24 UTC
Looks like a follow-up to issue 88893
Comment 5 Armin Le Grand 2009-10-21 14:13:44 UTC
AW->OD: Looked in a OOO320 m1 and there seem to be more than this problem. Help
is a SW AFAIK, maybe repaint is not adapted for Pre/postPaint at all? Please
have a look, i have no idea about help and it's usage of SW.
Comment 6 Oliver-Rainer Wittmann 2009-10-21 17:15:09 UTC
The Help uses the Writer in online view with read-only document. Nothing special
here - the same paint routines are used as in the "standard" Writer.

I can not reproduce the described defect under Windows 2003 with OOO320m1,
OOO320m2, DEV300m60 and DEV300m61. The paint routines in the Writer code are not
platform-dependent. Thus, I do not expect that the Writer code is responsible
for this defect.

Please further evaluate this problem?
On which platforms does the defect occurs?
Since which version does the defect occurs?
Does the defect also occurs in Writer in online view with similar documents?
Comment 7 andreschnabel 2009-10-21 17:51:02 UTC
tried with writer (will attach an example) - and I'm able to reproduce thesame
problem. I even happens in print view, edit mode. But I need to zoom the
document with an active selection.

change sumary, setting accesibility keyword
Comment 8 andreschnabel 2009-10-21 17:52:17 UTC
Created attachment 65517 [details]
select some text, then zoom the view
Comment 9 andreschnabel 2009-10-21 18:25:30 UTC
Created attachment 65518 [details]
same example with embedded graphic
Comment 10 Uwe Fischer 2009-10-22 08:42:20 UTC
I guess you would need a stand-alone Linux box to see this bug. I only have
stand-alone Windows PCs and virtual Linux and Solaris displays with very limited
graphics capabilities (Graphics Output and Transparency settings on Options-View
tab page are grayed out).
We don't know which Linux and whether some graphics gimmicks were used by OP.
Comment 11 andreschnabel 2009-10-22 08:55:40 UTC
my configuration is:
A) kubuntu 9.04 32bit, 
   KDE 4.3, 
   local display, 
   current Xorg X-server, 
   ATI graphics
B) RedHat enterprise 3 32bit,
   KDE 3.5.1,
   remote display,
   cygwin XServer on Windows
Comment 12 andreschnabel 2009-10-22 09:03:07 UTC
I think, I found what triggers the problem:
You need to have a graphic with transparency in the visibla area then the
problem occures.
Graphics without transparencies are ok.
Comment 13 Mechtilde 2009-10-23 16:26:15 UTC
I can reproduce it on my eeepc with the latest attached document.
Comment 14 joerg.skottke 2009-10-27 09:39:38 UTC
Confirmed on Ubuntu Karmic / OOO320m2.
When a help page contains graphics we only have the frame around the selection, 
in writer the selection is lost upon each focus change.

The problem did not exist in OOo3.1.1.
A machine for reproduction is available.
Comment 15 stefan.baltzer 2009-10-27 10:03:38 UTC
SBA->AW: Please proceed, thx.
Comment 16 stefan.baltzer 2009-10-27 17:56:45 UTC
This is reproducible on Suse 10.1 and OpenSuse 11, too.
This is broken since DEV300_m50 at least (could not find older builds).

A variation (maybe help to circle this in):
 - Open second bugdoc (with embedded graphic)
 - Unmaximize the application window if needed
 - Select the first paragraph
 - Shrink and enlarge the window size so that the graphic gets out of view and
back again
-> When the graphic is within the view area, the selection background vanishes
-> When the graphic is out of the view area, the selection background comes back

Note that shrinking the view within the online help brings the same effect.
I adjusted the summary to meet the findings.
Comment 17 Armin Le Grand 2009-10-28 11:35:25 UTC
AW->HDU: Checked down to X11SalGraphics::drawAlphaBitmap where the transparent
part is visualized using a BitmapEx (checked content, it's correct) which gets
painted. Returning false here makes it work, so it happens here somehow.
I could reproduce running remote on v60x-so16 and using XMing as XServer.
To reproduce: Start SW, type 'dt' + F3 (text expansion), select all (CTRL-A).
Hold CTRL, use muse wheel to zoom out (not in), On smallest zoom (page evry
small top-left), play with the last 2-3 zoom steps. The visualisation will start
to not paint transprency left and top, looks like clipped. In that state, You
can use CTRL+SHIFT+R for repaints which will keep the error.

Has nothing to do with transparent graphics, but maybe with SW and various
XRender implementations. Please have a look.
Comment 18 2009-11-06 16:04:51 UTC
Recycled render pictures need to have their clip regions reset...
Comment 19 2009-11-09 09:37:00 UTC
Fixed in CWS ooo32gsl04.
Comment 20 2009-11-11 09:39:28 UTC
@sba: please verify in CWS ooo32gsl04
Testing hint: test scenarios with clipped antialiased graphics on X11 platforms which support the render extension
Comment 21 stefan.baltzer 2009-11-19 14:15:02 UTC
Verified in CWS ooo32gsl04.
Comment 22 Mechtilde 2009-11-28 14:32:09 UTC
verified in OOO320_m6 -> closed
Comment 23 2009-12-01 07:46:20 UTC
*** Issue 105843 has been marked as a duplicate of this issue. ***