635897 - Weird rendering of the Identity information and Edit bookmark widgets with metacity compositor

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect)

Description

[Julen Ruiz Aizpuru]

Attachment: Identity widget with completely black shadow

Currently when you click on the Identity icon on the location bar, a widget is displayed showing current site's identity information, but the widget's shadow is not correctly rendered on the first time. On subsequent clicks the shadow is not always displayed correctly either. The buggy behaviour seems to be inconsistent.

Something similar happens when you click the star icon to bookmark the current location, but the effect is even worse when you try to pick a specific folder by clicking the dropdown icon — the UI ends up in a completely useless state.

See the attached screenshots for reference.

The Minefield build I am using is the following:
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre

Comment 1

[Julen Ruiz Aizpuru]

Attachment: Edit bookmark widget in a completely useless state

Comment 2

[Hussam Al-Tayeb]

It's because of the small arrow that was very recently added to those widgets.

Comment 3

[Yann Brelière]

I have had this problem on one of my computers (at home): on first click, the shadow is completely black, as in the first attachment, and then, the shadow's transparency is ok, but not always well positioned.
I don't have the problem (at work), as there is no shadow at all.

I believe that the difference is that the first one, with the broken shadows, uses metacity (with compositing activated), while the second one (without shadows) uses Compiz.

Comment 5

[Guillermo López :willyaranda (probably SLOW response)]

blocking 2.0?

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Reporter, you aren't using the default theme. Please start Firefox in safe mode and retest.

Comment 7

[Julen Ruiz Aizpuru]

Run Firefox in safe mode with a new profile and the buggy behaviour remains the same.

Tested with several GTK themes, including Darkilouche, elementary, Candido, and the GNOME's default Clearlooks.

Comment 8

[Karl Tomlinson (:karlt back Feb 10)]

Would you mind trying a build from here, please?
(64-bit builds should be there soon.)

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-b9d3bd833d86/

It would also be helpful to confirm compiz as the window manager (check the list of running processes) and determine compiz and xorg-server versions.

It sounds like the compositor is not handling shape changes appropriately.
The difference in that build is that the shape change happens before drawing.
That may or may not be more to the compositors liking.

Comment 9

[Julen Ruiz Aizpuru]

Tried the 64bit build with no success.

I'm not using Compiz as a window manager but Metacity (Compiz isn't installed on this system).

Installed versions are:
Metacity 2.30.1
xorg-server 1.7.6

Comment 10

[Karl Tomlinson (:karlt back Feb 10)]

Thanks, Julen.

I can reproduce with metacity 2.30.3 and xorg-server 1.9.4.

Shaping before drawing avoids the solid black as in attachment 514181 [details], though the compositor's shadow does not take the shape into account.
I still see situations like attachment 514182 [details] sometimes.

This looks like a bug in metacity not handling dynamic shape changes.

Comment 11

[Julen Ruiz Aizpuru]

Yes, if I disable compositing in Metacity then the rendering looks acceptable:
gconftool-2 -s '/apps/metacity/general/compositing_manager' --type bool false

There are some bugs in GNOME's bugzilla that may be related to this:
https://bugzilla.gnome.org/show_bug.cgi?id=571854
https://bugzilla.gnome.org/show_bug.cgi?id=576589
https://bugzilla.gnome.org/show_bug.cgi?id=596464

Comment 12

[Karl Tomlinson (:karlt back Feb 10)]

https://bugzilla.gnome.org/show_bug.cgi?id=576589 describes the problem precisely, thanks.

Comment 13

[Florian Hänel [:heeen]]

Attachment: kde, compositing enabled

I get the same on KDE, compositing enabled. 
OpenGL vendor string: NVIDIA Corporation                                       
OpenGL renderer string: GeForce 8400 GS/PCI/SSE2                               
OpenGL version string: 3.2.0 NVIDIA 195.36.15

Comment 14

[Karl Tomlinson (:karlt back Feb 10)]

Florian is using OpenSuSE 11.2, so I assume that means kwin 4.3.5.

I haven't managed to reproduce with kwin 4.4.5 (except for the initial black flicker), so the issue may have been resolved in kwin.

End of life for OpenSuSE 11.2 is May 12.  Please report if the issue still exists with a more recent kwin.

If we were to workaround the metacity situation, RGBA windows (bug 408284) would be the preferred approach.

Comment 15

[Florian Hänel [:heeen]]

opened bug 651076 for the kwin issue

Comment 16

[Julen Ruiz Aizpuru]

I'm currently running Aurora and it seems the bug isn't present anymore, the shadows are properly rendered.

Have there been any changes related to this recently? Can someone confirm this please?

Comment 17

[Karl Tomlinson (:karlt back Feb 10)]

Bug 655932 (described in comments 8-10) landed for Mozilla 6, but I wouldn't expect that to change the shadows.
Bug 635903 is related and also landed for Mozilla 6, but I didn't expect that to have any effect.

Are you still running the same metacity?

Comment 18

[Julen Ruiz Aizpuru]

Oh sorry, just tested again and it seems the issue remains. No idea why it didn't happen yesterday. Metacity version is the same, btw.

Sorry for the bugmail noise.

Comment 19

[[:Aleksej]]

Bug 741271 may be a duplicate of this one.

Comment 20

[Karl Tomlinson (:karlt back Feb 10)]

Comment on attachment 514181 [details]
Identity widget with completely black shadow

This should no longer be happening since bug 655932 was fixed.

Comment 22

[Julen Ruiz Aizpuru]

Is this already in nightly? Which build should I use to verify this?

Comment 23

[Karl Tomlinson (:karlt back Feb 10)]

Should be in the next nightly.

Comment 24

[Julen Ruiz Aizpuru]

Thanks for fixing this!

Verified in 18.0a1 (2012-10-08) (Linux x86_64)