Bug 277613 - Corruption around firefox menus and tooltips
Summary: Corruption around firefox menus and tooltips
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 279761 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-12 11:41 UTC by Todd
Modified: 2012-12-05 00:33 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Screenshot of the problem (13.08 KB, image/png)
2011-07-12 11:41 UTC, Todd
Details
Logfile opening Tools menu (5.48 KB, application/x-gzip)
2011-08-08 12:38 UTC, Tobias
Details
New logfile (5.46 KB, application/x-gzip)
2011-08-08 13:34 UTC, Tobias
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Todd 2011-07-12 11:41:22 UTC
Created attachment 61803 [details]
Screenshot of the problem

Version:           4.0 (using Devel) 
OS:                Linux

When I have compositing enabled on KDE 4.7, an area around both menus and tooltips in firefox is corrupted.  It shows a large, repeated pattern of distorted images (see attachment for an example).  This only happens when the oxygen-gtk theme is enabled, it doesn't happen for any other theme.

Reproducible: Always

Steps to Reproduce:
1. Enable desktop effects
2. Enable the oxygen-gtk theme
3. Open firefox
4. Click on a menu
5. Hover your mouse over a tab

Actual Results:  
Area around menu and tooltip is corrupted

Expected Results:  
Area around menu and tooltip appears normal

This occurs on both NVidia and ATI graphics cards.  Disabling direct rendering, openGL 2, or vsync does not fix it.  Disabling translucency, blur, or highlight window does not effect it.  There is no longer a listing for the shadow effect, so I could not disable that to test it, nor could I enable the BeShadowed effect (it won't let me).  Changing the firefox theme did not fix it.  Disabling compositing does fix it.
Comment 1 Hugo Pereira Da Costa 2011-07-12 12:03:31 UTC
Re-assigning to kwin (cause this is a kwin issue).
I "think" it is a duplicate of an existing bug, and that it has been fixed.
To be confirmed by Martin/Thomas
Comment 2 Martin Flöser 2011-07-12 15:24:01 UTC
should be fixed with c1ac45e1eb14d584f1f2d1ec2c39a19b2ca1325e


@hugo: please remember to change the assignee or we won't get emails.
Comment 3 Ismail Donmez 2011-07-12 15:27:36 UTC
Isn't the fix is in RC2? The bug reporter is using openSUSE 4.7rc2 packages and also says it happens with ATI cards too.
Comment 4 Martin Flöser 2011-07-12 15:40:43 UTC
I don't see any information about the version (using Devel is not saying anything useful). Apart from that I don't know whether this is in RC2 or not, I only know that the fix is in 4.7 branch.
Comment 5 Ismail Donmez 2011-07-12 15:49:48 UTC
I checked and the fix is in KDE 4.7 RC2 indeed. Todd, can you confirm that you run 4.7 RC2?

kwin --version here says

Qt: 4.7.3
KDE Development Platform: 4.6.95 (4.7 RC2) "release 1"
KWin: 4.6.95 (4.7 RC2) "release 1"
Comment 6 Todd 2011-07-13 07:10:59 UTC
I am using "Using KDE Development Platform 4.6.95 (4.7 RC2) 'release 1'".  Sorry, I thought I put that in.  I just checked again and the problem still persists.  I checked and all of my KDE packages have that version (besides a couple translation files that aren't being used right now).
Comment 7 Todd 2011-07-13 07:11:52 UTC
Here is the exact version for kwin:

Qt: 4.7.3
KDE Development Platform: 4.6.95 (4.7 RC2) "release 1"
KWin: 4.6.95 (4.7 RC2) "release 1"
Comment 8 Martin Flöser 2011-07-14 04:34:48 UTC
a regression was spotted and should be fixed with 55986b32de9e5f5f66ac0c3448b26863cfc2dee0
Comment 9 Thomas Lübking 2011-07-14 10:43:19 UTC
I'm not sure that that fixed this (but may be implicitly)

a) Seems to affect Firefox only (are other Qt or "GTK2" -FF is not really one- applications affected?)

b) The bug was initially reported _before_ the patch with the regression fixed by that commit was even pushed (Tue, 12 Jul 2011 18:52:03 +0000 (20:52 +0200))

c) I cannot find 4.6.95 (4.7 RC2) "release 1" on projects.kde.org but it was apparently tagged July 5th - looong before the regression was pushed.

d) the regression was about ghost windows on Deleted but the scrot shows pixel garbage (uninitialized pixmap?) around a present (!) tooltip.
Comment 10 Todd 2011-07-14 10:59:53 UTC
I checked some more programs.  Amongst ones I tried, no others were affected:

GTK: gimp, inkscape, g3data
Qt: eric, scribus, Q7Z
Other: LibreOffice

And yes, the problem is pixel garbage (sometimes matching icons from the program, which would be compatible with pixmaps).
Comment 11 Thomas Lübking 2011-07-14 11:14:28 UTC
Ok, I guess this is a conflict between oxygen-gtk and XUL then.
Do you use FF layer acceleration? (this does also affect the UI which is actually XUL...)

about:config, filter for "accel" or "layer"
Comment 12 Hugo Pereira Da Costa 2011-07-14 11:21:05 UTC
@Todd: which version of firefox are you using ?
Comment 13 Todd 2011-07-14 11:38:05 UTC
Changing layers.acceleration.disabled from false (default) to true does not change anything.

I am using Firefox 5.0
Comment 14 Hugo Pereira Da Costa 2011-07-14 11:43:13 UTC
@Thomas
I'm not sure I understand how this is a conflict between oxygen-gtk and XUL ... 
Only thing oxygen-gtk does is create 8 X11 Pixmaps, and pass them, via X properties to the Menu WinID. 

Can you ellaborate ? Do you think the X11 pixmap is corrupted *at its creation* because of XUL ? Or that the X property is corrupted ? Or what ?

Thanks in advance for clarifying.

(also: I am also running Firefox 5.0 here, with oxygen-gtk-1.1.1, and intel Graphics Card, and have no problem. What do I miss ?)

Hugo

PS: re-oppening the bug, as UNCONFIRMED.
Feel free to re-assign to oxygen if you feel like it, though I'm pretty clueless on how to fix)
Comment 15 Thomas Lübking 2011-07-14 12:01:04 UTC
I had thought the OpenGL acceleration (in FF) might "somehow" have freaked the Pixmap format.
If the the Pixmap on the server pointed by the prop was invalid we'd just get an X error (invalid pixmap) - the Pixmap must either have been "freed" w/o removing it from the server or your paint instructions were redirected/converted into the void -> pixmap's junk in memory.

Since the acceleration is (iirc) only activated for nvidia systems, that might have caused it, but for Todds reply... sigh :-(

I'm gonna install a git version of oxygen-gtk and have a look.
@Todd: do you use an nvidia GPU?
Comment 16 Thomas Lübking 2011-07-14 12:19:14 UTC
Nope, no issues here at all. (but force-enabled causes black windows, that's a FF "regression" between 4 & 5. My GPU is probably too old :'(

Last guess:
@Todd, please try "firefox -safe-mode"
Comment 17 Todd 2011-07-14 12:24:36 UTC
The problem is still present when running firefox in safe mode.

The problem is present on two different computers, one running an NVidia GPU and another running an ATI GPU.  So it is not NVidia-specific.
Comment 18 Hugo Pereira Da Costa 2011-07-14 12:37:31 UTC
pixmaps being freed to early, might be a possibility (though unlikely). 
I'll look into it ...
Comment 19 Ismail Donmez 2011-07-28 12:58:24 UTC
Any news on this?
Comment 20 Todd 2011-07-28 13:05:03 UTC
I'm not seeing it in 4.7 final.
Comment 21 Craig Drummond 2011-08-01 10:27:28 UTC
I can see these artifacts with kwin 4.7.0, Firefox 5.0, and oxygen-gtk 1.1.50
Comment 22 Hugo Pereira Da Costa 2011-08-01 10:44:05 UTC
not being able to reproduce on neither intel nor nvidia here, (with kde and all the rest from trunk) makes it very hard to fix :(
Double checking, pixmaps can't be freed too early in oxygen's code. (they're basically freed when oxygen-gtk lib is unloaded). So, no clue.
Comment 23 Craig Drummond 2011-08-01 18:58:07 UTC
This is probably a driver and/or a kwin issue then. With NVidia, firefox is ok - with intel graphics the corruption appears.
Comment 24 Tobias 2011-08-08 08:52:52 UTC
Just want to add my experience to this bug. Lately a lot of things have changed in my system:
KDE 4.7 installed from openSUSE repos.
openSUSE recently released some security updates (kernel patch among others)
I upgraded NVIDIA driver from 275.21 to 280.13

Before these changes menus where just fine in Firefox but after changes they are corrupted.

On my system the only change that fixes the problem is downgrading oxygen-gtk 1.1.1 that is included with the 4.7 repos to 1.0.5 that is in the 4.6 release repos for openSUSE).

Downgrading NVIDIA driver does not help.
Comment 25 Hugo Pereira Da Costa 2011-08-08 10:07:11 UTC
Git commit c6e3de7cce4c4c5879b7dfa758c314d203a698b6 by Hugo Pereira Da Costa.
Committed on 08/08/2011 at 11:45.
Pushed by hpereiradacosta into branch 'master'.

Added debug info for shadow pixmaps.
CCBUG: 277613

M  +26   -0    src/oxygenshadowhelper.cpp

http://commits.kde.org/oxygen-gtk/c6e3de7cce4c4c5879b7dfa758c314d203a698b6
Comment 26 Hugo Pereira Da Costa 2011-08-08 10:10:19 UTC
For people having the problem and willing to help understand the issue, 
I added more debug messages to oxygen-gtk.
Could someone 

- get oxygen-gtk from 'master' (it is safe: the code is stable)
- compile it in "debug" mode (that is: cmake -DOXYGEN_DEBUG=1)
- run firefox (or thunderbird) with it, redirecting the log into a file
(that is: firefox >& log)
- try open a (corrupted) menu, and close
- post the resulting log file here (as attachment)

Thx !
Comment 27 Tobias 2011-08-08 12:38:16 UTC
Created attachment 62660 [details]
Logfile opening Tools menu
Comment 28 Tobias 2011-08-08 12:39:16 UTC
Sure,
Hope that log file above can help!

Best regards,
Tobias
Comment 29 Hugo Pereira Da Costa 2011-08-08 12:58:33 UTC
@Tobias: Helps a lot ! 
"IA__gdk_x11_visual_get_xvisual (...)"

That's the bad guy, most likely (message appears 16 times, which is the number of shadow pixmaps we create. So very good candidate, and I don't have it here).

Now, well, I cannot find the debug info I added to oxygen-gtk with the commit from #25. Did you first update the oxygen-gtk code ? (git pull) ? 
If not, could you give it another shot ? 
Lines that should appear are such as:

Oxygen::ShadowHelper::reset
Oxygen::ShadowHelper::initialize
Oxygen::ShadowHelper::createPixmapHandles

In the meanwhile I'll investigate the origin of the above.
Will keep you posted.

Hugo
Comment 30 Tobias 2011-08-08 13:34:02 UTC
Created attachment 62664 [details]
New logfile
Comment 31 Tobias 2011-08-08 13:37:51 UTC
Sorry,
Thought I got the updates (didn't have the code at all so I downloaded a tarball and ran initrepo.sh).
Anyway, attached is a new file which should contain the new messages.
Comment 32 Hugo Pereira Da Costa 2011-08-08 13:40:28 UTC
Thanks ! 
I should submit a patch (that checks the guilty missing Visual) soon (few minutes).

It may (or may not) result in having no shadows for firefox and company
(because I do not know the origin of this visual being NULL), but at least
- no more corruption
- correct shadows for other gtk apps.

Will keep you posted.
Comment 33 Hugo Pereira Da Costa 2011-08-08 13:40:49 UTC
Git commit 1e0dc79cb39134ecdf22bead31c78cd40c242fa2 by Hugo Pereira Da Costa.
Committed on 08/08/2011 at 15:38.
Pushed by hpereiradacosta into branch 'master'.

Added checks on Screen, Display, and Visual before allocating the pixmaps needed for
shadows.

CCBUG: 277613

M  +43   -2    src/oxygenshadowhelper.cpp

http://commits.kde.org/oxygen-gtk/1e0dc79cb39134ecdf22bead31c78cd40c242fa2
Comment 34 Hugo Pereira Da Costa 2011-08-08 13:42:19 UTC
Ok. Comment #33 should "fix" the issue.
Please report back  
- whether corruption is gone as expected
- whether you do have shadows for menus or not. (if not, its still an issue, but at least a less annoying one).
Comment 35 Hugo Pereira Da Costa 2011-08-08 13:45:56 UTC
Git commit b150eee18b853d889aa0c8556762fac4833dfa5b by Hugo Pereira Da Costa.
Committed on 08/08/2011 at 11:45.
Pushed by hpereiradacosta into branch '1.1'.

Added debug info for shadow pixmaps.
CCBUG: 277613

M  +26   -0    src/oxygenshadowhelper.cpp

http://commits.kde.org/oxygen-gtk/b150eee18b853d889aa0c8556762fac4833dfa5b
Comment 36 Hugo Pereira Da Costa 2011-08-08 13:45:56 UTC
Git commit e9f836bf20edbf45926f13fa681400d56e4275d9 by Hugo Pereira Da Costa.
Committed on 08/08/2011 at 15:38.
Pushed by hpereiradacosta into branch '1.1'.

Added checks on Screen, Display, and Visual before allocating the pixmaps needed for
shadows.

CCBUG: 277613

M  +43   -2    src/oxygenshadowhelper.cpp

http://commits.kde.org/oxygen-gtk/e9f836bf20edbf45926f13fa681400d56e4275d9
Comment 37 Tobias 2011-08-08 14:10:18 UTC
Corruption gone with the patches, unfortunately the shadows as well (but for me that's a minor issue).

Thanks for quick support!
Comment 38 Hugo Pereira Da Costa 2011-08-08 14:13:53 UTC
I believe the shadows being gone could be due to some "optimization" on the firefox side. Hopefully, kwin might provide some "default" shadow when none is installed (as here) in the near future, which would "fix" the issue (it would not have the problem that oxygen-gtk has). 

Unless some kwin dev (Thomas ?) has any clue why I cannot have access to the Argb Visual via gtk inside firefox (XUL) and if he knows a way to circumvent it ? 

(mmm. Maybe I could try some X calls directly, since the guy is used for creating native X11 pixmaps).

Still, closing.
Comment 39 Thomas Lübking 2011-08-08 18:55:59 UTC
Hummm? gdk ranks screen over display??
Well, I saw Episode VI before Episode I, so... ;-)

Anyway, i guess FF will either setenv("XLIB_SKIP_ARGB_VISUALS", 1); what you could test via getenv() or there might be a clash with FFs OpenGL capabilities.
See bug #262064 and check the window for a RGB_DEFAULT_MAP property.

Otherwise I've presently no other ideas at hand, sorry in case.
Comment 40 Ruslan Kabatsayev 2011-08-09 19:33:56 UTC
*** Bug 279761 has been marked as a duplicate of this bug. ***
Comment 41 FireIcer 2012-12-05 00:33:58 UTC
Hello all,

I recently came across this problem, pixel garbage around tooltips and all GTK+ applications menus. No theme change made a change nor did disabling desktop effects. 

I tried all sorts of things but decided to upgrade the GTK+:2 version from:

gtk+-2.24.10-r1 >> gtk+-2.24.13-r1

This solved the problem or seems to have. My distro had the above versions masked by keyword as i use gentoo. For those not familiar with Gentoo the keyword masks protect the package manager from compiling packages that wont work on a spacific archetectures. e.g. X86 vs ARM or amd64 etc. 

I guess there is an issue with newer packages that use the GTK:2 engine working with the older gtk+ version. (a small gentoo portage glitch maybe)

Unmasking by keyword fixed it for me anyway so if anyone else runs into the problem they can check there versions of the file.

Hope it helps someone.