Created attachment 265475 [details] [review]
window-actor: Remove unobscured region optimization in get_paint_volume

This has been done because it looked like an obvious thing to do but never got
tested in 3.10 due to a thinko and now that it got fixed it causes problems
for off screen windows like the legacy tray icons.

So just remove it as it does not seem to gain much but cause problems.

Tested, seems to work.

Created attachment 265547 [details] [review]
window-group: Don't set unobscured region when we have mapped clones

This is results into a wrong paint volume and thus drawing artifacts for
untransformed clones (like the legacy tray icons).

---

Does this one work as well?

(In reply to comment #3)
> Created an attachment (id=265547) [details] [review]
> window-group: Don't set unobscured region when we have mapped clones
> 
> This is results into a wrong paint volume and thus drawing artifacts for
> untransformed clones (like the legacy tray icons).
> 
> ---
> 
> Does this one work as well?

No, the bug remains (tried on top of latest mutter-git).

Review of attachment 265547 [details] [review]:

Doesn't help / work.

Created attachment 267718 [details] [review]
window-actor: Fix unobscured_region handling when computing paint volume

We currently ignore the unobscured region when we have mapped clones in
meta_window_actor_process_damage and meta_window_actor_damage_all but
use it unconditionally when computing the paint volume.
This is wrong. We should ignore it there as well or we will end up with
empty clones if the cloned window is completly obscured
(like the tray icons in gnome-shell).

---

OK finally got time to really look it. This should fix it and leave the 
optimization in place.

Review of attachment 267718 [details] [review]:

This looks correct.

Jasper's surface-content branch moves this code around: https://git.gnome.org/browse/mutter/commit/?h=wip/surface-content&id=14d921f6850426ae8212d07f01e56739c3d7b1fe.

Perhaps we should factor out an effective_unobscured_region() function like that patch does and use it here already?

(In reply to comment #7)
> Review of attachment 267718 [details] [review]:
> 
> This looks correct.
> 
> Jasper's surface-content branch moves this code around:
> https://git.gnome.org/browse/mutter/commit/?h=wip/surface-content&id=14d921f6850426ae8212d07f01e56739c3d7b1fe.
> 
> Perhaps we should factor out an effective_unobscured_region() function like
> that patch does and use it here already?

We could do that or just get the fix in and use effective_unobscured_region once that branch lands. 

I am fine either way ... Jasper?

The patch can land for now, and I'll fix up my code when I rebase.

I’m still experiencing this bug in 3.12.1. In fact it’s become a bit more severe in that the icons now consistently come up empty, while in 3.10 they sometimes worked and only became blank when something changed on the client side.

Another change has been that as of 3.12, when the icons are not invisible, they sometimes show as what appears to be a colored block of ~5x5 pixels. In 3.10, the icons were sometimes impropertly sized, but always appeared to be valid icon-sizes.

I can reproduce this in all of my tray-enabled applications, which are Gajim, Owncloud, Steam, Tomboy and Guake. But I suppose these are all legacy-based?

Could someone reopen this for 3.12 please? Thank you!

(In reply to comment #11)
> Could someone reopen this for 3.12 please? Thank you!

Sure but fwiw I just tried to reproduce but couldn't.

Any info that would be helpful diagnosing? Is there some way for me to inspect this with the looking glass? I see the issue on all of my Gnome machines.

The bug seems to be racy; during the last week the 3.12 behavior was again the same as in 3.10, i.e. some of the tray icons come up okay occasionally, but become invisible as soon as the client does something with them.

Created attachment 275524 [details]
Invisible or improperly rendered tray icons

Icons partly invisible, partly rendered infitesimally small, partly wrongly sized (owncloud). The yellow pixel is the tomboy icon.

On that screenshot, none of the icons is currently invisible. On invisible icons, I just see the blank space and the mouse-over overlay.

Actually, those pixel-sized icons seem to be new with 3.12, in 3.10, they were only completey invisible or improperly-sized like the owncloud one.

I'm seeing this as well, on Debian's 3.12.2-2. Most of the misrendering survives after a shell restart, as well.

Still present in 3.14.1.

*** Bug 731857 has been marked as a duplicate of this bug. ***

*** Bug 741518 has been marked as a duplicate of this bug. ***

*** Bug 743337 has been marked as a duplicate of this bug. ***

As mentioned in bug 741518, this is the list of programs I see either too small of invisible icons of:

VLC              very small
Transmission     very small
Skype            medium size
Pidgin           very small
Dropbox          invisible
Gajim            invisible
Redshift         very small
GoldenDict       very small

Please see attachment 292700 [details]. GNOME 3.14.

*** Bug 729016 has been marked as a duplicate of this bug. ***

*** Bug 730288 has been marked as a duplicate of this bug. ***

*** Bug 733992 has been marked as a duplicate of this bug. ***

*** Bug 744160 has been marked as a duplicate of this bug. ***

drago, could you try to reproduce it once again? At least dropbox client is affected, but if you prefer something opensource, there's a Qt5 systray example.

*** Bug 744231 has been marked as a duplicate of this bug. ***

drago, could you try to reproduce it once again?

Tray icons quite often disappear after a lock screen, after suspend and after connecting or disconnecting an external monitor.

Probably related: bug 721596 (includes code example)

(In reply to Christoph Reiter (lazka) from comment #30)
> Probably related: bug 721596 (includes code example)

That's this bug ...

> Probably related: bug 721596 (includes code example)

code example -- exists in dublicate of this bug (bug-id of dublicate: 731857 )

Well, this bug was here for years, at least since 3.8, see #699306

(In reply to Florian Müllner from comment #31)
> (In reply to Christoph Reiter (lazka) from comment #30)
> > Probably related: bug 721596 (includes code example)
> 
> That's this bug ...

Copy paste bug, I mean bug 733647

Sorry for the noise.

I haven't seen this with the new legacy tray from bug 745162, so I may have accidentally fixed this. Could someone check whether the issue is still present on current master?

(In reply to Florian Müllner from comment #35)
> I haven't seen this with the new legacy tray from bug 745162, so I may have
> accidentally fixed this. Could someone check whether the issue is still
> present on current master?

Any chance to get backport for 3.14?

No. This is a major UI change as part of the notification redesign.

Ok, then I'll wait for 3.16

(In reply to Florian Müllner from comment #35)
> I haven't seen this with the new legacy tray from bug 745162, so I may have
> accidentally fixed this. Could someone check whether the issue is still
> present on current master?

Is there an easy way to try it? I tried Fedora Rawhide and I don't see anything new (but I don't know where to look for it, there is no link to the actual mockups in bug 745162). I also tried today's GNOME Continuous, and I don't see any message tray. But it might be caused by the limited number of applications available in there, maybe none of them actually use that tray anymore (Clocks used to in GNOME 3.14).

(In reply to Kamil Páral from comment #39)
> Is there an easy way to try it? I tried Fedora Rawhide and I don't see
> anything new

It's not in a tarball yet. There's one due, but we are still waiting for a couple of mutter fixes to make it in - still, with a release out later today, it should appear in rawhide tomorrow at the latest.


> I don't see any message tray. But it might be caused by the limited number of
> applications available in there, maybe none of them actually use that tray
> anymore (Clocks used to in GNOME 3.14).

The old message tray does not exist anymore. It used to contain two kinds of items, notifications (which are now located in the calendar drop-down) and legacy status icons (which were dropped temporarily in 3.15.90 and brought back in a small bottom tray in bug 745162).
GNOME applications generally no longer use legacy tray icons but notifications (including Clocks, which never used a legacy icon). Prominent examples of apps that still do are dropbox, sparkleshare and pidgin, and some like xchat and transmission can be configured to use one as well.

Tested with trunk now: It kinda works, but the size switches 7 times between 24 and 25 px and the bar changes its height with it.. It settles a second after the tray icon is shown.

tried with transmission and pidgin, both show up with the expected size now.

(In reply to Matthias Clasen from comment #42)
> tried with transmission and pidgin, both show up with the expected size now.

Issue is still here though now it is better masked. Can you try test case from 

https://bugzilla.gnome.org/show_bug.cgi?id=731857 ?

Open tray (it should stay visible) and run test - there is no icon until tray will be redrawn - e.g. new tray icon added or another tray icon deleted. Icon also appears when you hide and open tray again. May be it is not big deal for gnome users but unfortunately this issue also affects Cinnamon users where you can't hide/open tray so only way to redraw tray is Cinnamon or application restart.

(In reply to Vladimir Didenko from comment #43)
> (In reply to Matthias Clasen from comment #42)
> > tried with transmission and pidgin, both show up with the expected size now.
> 
> Issue is still here though now it is better masked. Can you try test case
> from 
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=731857 ?

I can reproduce this issue with trunk.

lets untangle the issues here. Is this bug about status icon sizes ? if yes, please file a new one about appearing/disappearing status icons. Thats a separate issue.

@Matthias, wasn't it closed as a duplicate of this bug?

Btw, I don't think that NEEDINFO reflects current status of this bug, since it was already reported that issue is still here.

(In reply to Vasily Khoruzhick from comment #47)
> Btw, I don't think that NEEDINFO reflects current status of this bug, since
> it was already reported that issue is still here.

Sure, though "happens with real applications in the wild" and "fails with a contrived test case that does stupid things" makes a huge difference on whether this bug should be continue as 3.16 blocker bug.

dropping from target, I couldn't find any obvious or severe brokenness here.

(In reply to Florian Müllner from comment #48)
> Sure, though "happens with real applications in the wild" and "fails with a
> contrived test case that does stupid things" makes a huge difference on
> whether this bug should be continue as 3.16 blocker bug.

It happens for me with real applications in the wild with 3.14 (dropbox, skype, viber, almost every app with tray icon). And I usually follow this debugging rule: "if you didn't fix it, then it's not fixed". There were not an explicit fix for this bug, so I suppose that 3.16 is still affected.

Except that a fair part of the implementation has been replaced completely, and testing so far suggests that applications that were affected in 3.14 work much better in 3.16 (most importantly: they are not completely invisible).
If the problem has indeed been reduced to some jitter as suggested in comment #41, then there are simply more important issues to resolve than investing time in perfecting temporary support for a legacy feature.

Can somebody please share a screenshot that would show me where to find the new systray? I'm probably completely dumb, but I can't find it no matter which app I run - pidgin, transmission, goldendict, etc. I'm using gnome-shell-3.15.91-1.fc22.x86_64.

(In reply to Kamil Páral from comment #52)
> Can somebody please share a screenshot that would show me where to find the
> new systray? I'm probably completely dumb, but I can't find it no matter
> which app I run - pidgin, transmission, goldendict, etc. I'm using
> gnome-shell-3.15.91-1.fc22.x86_64.

Move your cursor into the lower left corner of your primary monitor.

For anyone with the same problem - the new systray appears only if you have an app with a "legacy" icon running. It is available on your main desktop, *not* in the overview mode. It appears as a few pixels wide gray bar in the lower left corner of your primary screen, you have to click on it with your mouse to expand it. There appears to be no keyboard shortcut to focus it, expand it, nor collapse it.

(In reply to Kamil Páral from comment #54)
> For anyone with the same problem - the new systray appears only if you have
> an app with a "legacy" icon running. It is available on your main desktop,
> *not* in the overview mode. It appears as a few pixels wide gray bar in the
> lower left corner of your primary screen, you have to click on it with your
> mouse to expand it. There appears to be no keyboard shortcut to focus it,
> expand it, nor collapse it.

If you want to file a bug about the discoverability of the new system tray implementation, please do so.

Created attachment 299094 [details]
invisible gajim icon in new legacy tray

(In reply to Allan Day from comment #55)
> If you want to file a bug about the discoverability of the new system tray
> implementation, please do so.

Thanks, I filed bug 746022, bug 746025 and bug 746026.

Regarding this bug, I tested the following applications:
transmission
pidgin
goldendict
gtk-redshift
skype
dropbox
gajim

Except for gajim, I saw no issues.

With gajim, I experienced an invisible tray icon a few times (3 times out of 40-50 runs), see the attached screenshot. I assume it tries to fit the icon size to the tray size, because sometimes it's visible that originally the gajim size was very small and then expanded to the tray size. It seems this approach fails from time to time, a race condition.

I also saw legacy tray size jumping up and down a bit a few times when starting gajim. The tray seemed to increase in height by a few pixels for a split of a second, and then shrank back to the default size again.

I don't know whether it is a problem in the new legacy tray, or in gajim.

gnome-shell-3.15.91-1.fc22.x86_64

Viber still has a blank icon in new tray.

gnome-shell-3.15.91

Skype and dropbox icon become blank after opening "power off" menu and clicking cancel. kvirc survives somehow.

Created attachment 302432 [details]
broken_tray_gnome_3_16.png

Could anyone from devs take a look at this issue? It's too annoying to restart gnome-shell to make tray icons visible again.

Somebody with the powers, please bump the Version to 3.16. Thanks.

If you need an app that fails always you can test with Cutegram [1].

[1] https://github.com/Aseman-Land/Cutegram

Could anyone from gnome-shell devs point me to a place in _native_ code where tray icons are handled? I'd like to debug this issue.

(In reply to Vasily Khoruzhick from comment #62)
> Could anyone from gnome-shell devs point me to a place in _native_ code
> where tray icons are handled? I'd like to debug this issue.

https://git.gnome.org/browse/gnome-shell/tree/src/shell-tray-icon.c
https://git.gnome.org/browse/gnome-shell/tree/src/shell-embedded-window.c
https://git.gnome.org/browse/gnome-shell/tree/src/shell-tray-icon.c

and well the damage and paint volume handling in mutter.

Looks like it's some mutter bug. After EndSessionDialog is opened, icons disappear even in 3rd party standalone tray (I tried with stalonetray). Any ideas from gnome-shell devs where to dig?

Gnome-shell crashes when clicking on (at least some of these) icons. See this downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1221782

I'm experiencing similar issues on Gnome 3.20, but only under Wayland session. 

For example the icon of Skype appears correctly, but the icon of KeePass is just a black rectangle.

There is a problem with clicking the icons. When the cursor pointer is above the icon the click event is not triggered, however if I click on the icon edge (where the image is transparent), then it works as expected.

Same here on latest debian stable ( Jessie 8.2 ). Refer http://i.imgur.com/fDyrtzf.png

(In reply to Géza Búza from comment #66)
> I'm experiencing similar issues on Gnome 3.20, but only under Wayland
> session. 
> 
> For example the icon of Skype appears correctly, but the icon of KeePass is
> just a black rectangle.
> 
> There is a problem with clicking the icons. When the cursor pointer is above
> the icon the click event is not triggered, however if I click on the icon
> edge (where the image is transparent), then it works as expected.

I have the 2nd issue under Wayland with GNOME 3.20 (Fedora 24), I don't know if we need to open another bug for it or not.

When I right click on the icon, I get the menu of the underlying app (Say Firefox), but when I click on the edge of the icon space, I get the correct menu. I can see the hover (mouse-over) effect by moving the cursor upon the icon area until it changes its color so I can click or right click on the icon. It's daunting but I don't have a choice here.

Created attachment 334216 [details]
screenshot of right-click on dropbox opens firefox menu

This is an image to clarify the issue of system tray under Wayland with GNOME 3.20 based on my previous comment.

Closing this ticket as WONTFIX as the legacy tray (introduced three years ago in 3.16) was meant as a temporary solution to encourage maintainers to move away from the concept of status icons and will not be included anymore in 3.26.

Users can install one of the existing extensions, either based on the still available XEmbed support or implementing the DBus-based StatusNotifier spec.

(In reply to André Klapper from comment #70)
> Closing this ticket as WONTFIX as the legacy tray (introduced three years
> ago in 3.16) was meant as a temporary solution to encourage maintainers to
> move away from the concept of status icons and will not be included anymore
> in 3.26.

Does this mean that no application can show a GtkStatusIcon (or similar from Qt) in gnome-shell 3.26, i.e. the legacy tray goes away without replacement? If yes, is there a public statement? In case those tray icons finally go away, I'll be filing bugs and patching a few applications which still use those tray icons.

(In reply to Christian Stadelmann from comment #71)
> Does this mean that no application can show a GtkStatusIcon (or similar from
> Qt) in gnome-shell 3.26, i.e. the legacy tray goes away without replacement?

Jein. The support for status icons is still in the underlying code, so extensions (like TopIcons and friends) can easily add them back. But there is indeed no replacement in gnome-shell itself, so status icons won't show up anywhere by default.


> If yes, is there a public statement?

Not yet. Allan is working on a statement, but unfortunately there was very little time between GUADEC (where the decision was made) and the .90 release (that marks the UI freeze), so we had to push out the change before communicating it properly.


> In case those tray icons finally go away, I'll be filing bugs and patching 
> a few applications which still use those tray icons.

Oh, that would be very welcome!

> But there is indeed no replacement in gnome-shell itself, so status icons won't show up anywhere by default.

Beyond the disruption caused by the abrupt and under-communicated deprecation, what is the suggested UI for long-running, "passive" apps like the owncloud client or redshift?

(In reply to Andreas Kloeckner from comment #73)
> Beyond the disruption caused by the abrupt and under-communicated
> deprecation, 

Nah, the *deprecation* of (ab)using the notification area for random application status icons already happened more than two years ago in GNOME 3.16...

Furthermore, we talk about a change in an unstable development version. If you're keen on following changes in unstable versions, see the line in the NEWS file at
ftp://ftp.gnome.org/pub/gnome/sources/gnome-shell/3.25/gnome-shell-3.25.90.news
Regarding upcoming stable releases to include this change, I expect the 3.26 release notes to cover this. Hence I cannot see "under-communication".

> what is the suggested UI for long-running, "passive" apps like
> the owncloud client or redshift?

Move the window to another workspace if you don't like to see windows of running UI applications, or install a 3rd party extension to get a legacy system tray.

(In reply to André Klapper from comment #74)

> Move the window to another workspace if you don't like to see windows of
> running UI applications, or install a 3rd party extension to get a legacy
> system tray.

And do you think that this is a good solution?

Why not add an option to HIDE a window and keep it running in dash/dock?

I'm actually quite surprised how opinionated (I was going to use the other word here) Gnome devs are. Topicons extension is so popular that it should have become part of Gnome. Your users *want* tray icons. No matter how deep you hide it. So find a way and give it to them.

(In reply to Óscar García Amor from comment #75)
> (In reply to André Klapper from comment #74)
> 
> > Move the window to another workspace if you don't like to see windows of
> > running UI applications, or install a 3rd party extension to get a legacy
> > system tray.
> 
> And do you think that this is a good solution?
> 
> Why not add an option to HIDE a window and keep it running in dash/dock?

You can hide the window by using "Super + H" or enabling the minimize button from GNOME Tweak tool. It'll be hidden, and pushed to the end of the App/Window Switcher stack.

The right thing for apps is to use background mode, which is the normal way in Android, iOS, and other OSes. They should send you notifications to pay attention to important things, and you open them only when you need them.

(In reply to Anass Ahmed from comment #77)

> You can hide the window by using "Super + H" or enabling the minimize button
> from GNOME Tweak tool. It'll be hidden, and pushed to the end of the
> App/Window Switcher stack.

Yes and No. "Super + H" not hides the app, only minimizes it. If I enter on Activities (top left corner or super key), I can see the application window, and it appears if I use "Alt + Tab".

A hidden app must be hidden, not minimized.
 
> The right thing for apps is to use background mode, which is the normal way
> in Android, iOS, and other OSes. They should send you notifications to pay
> attention to important things, and you open them only when you need them.

How? Keeping an icon on the tray to indicate they are working? ¯\_(ツ)_/¯

Anyway, has no sense that GNOME dev team simply hides the system tray. This remember me to the kids that break a vase and hide their pieces under the carpet hoping that the problem will solve itself.

(In reply to Óscar García Amor from comment #78)
> (In reply to Anass Ahmed from comment #77)
> 
> How? Keeping an icon on the tray to indicate they are working? ¯\_(ツ)_/¯
> 
> Anyway, has no sense that GNOME dev team simply hides the system tray. This
> remember me to the kids that break a vase and hide their pieces under the
> carpet hoping that the problem will solve itself.

Does Android/iOS provide a system tray? Is it a needed feature there?

Actually, it does. Both Android and iOS (and Windows and Mac OS) have systrays.
See that little clock icon in the upper right corner of your phone when you turn on the alarm? That is systray. See those little 2 triangles when you turn on bluetooth? That is systray. Same goes for GPS/screen rotation/etc... 

Those are icons sitting at the right top corner of your screen. Those are not notifications. Let me rephrase it. You get visual icons and not notifications for some events that happen in your phone. There are no "minimized" alarm windows nor notifications. Just an icon.

You're missing a huge point here. There are quite some apps that don't have actual UIs, but mere status icons. Let's say for example Dropbox.

Dropbox doesn't have an UI. It doesn't need one. The only thing Dropbox must do is sync files. And it shouldn't have to spam me with notifications each time it manages to sync a file. As long as I see Dropbox's icon in my systray I know it's syncing properly. Why would I want to dismiss tens of Dropbox messages notifying me about every file synced in my shared folders?

What about docker? Or Evernote's helper? Lastpass?

You're clearly ignoring real-world applications. What's even worse, you're trying to convince yourselfs that systray is not necessary when it clearly is.

But, hey, just my 2 cents. I really don't care about Gnome. Or Linux on the desktop. I moved on long time ago, mainly because this sort of stuff. I'm just posting this so you can get some real reasons/feedback.

Please wait for the full public statement to understand the background, the decision and the steps to take for the future.

You will have a good opportunity to provide feedback then with a better medium and context, rather than this unrelated bug.

(In reply to Florian Müllner from comment #72)
> (In reply to Christian Stadelmann from comment #71)
> > Does this mean that no application can show a GtkStatusIcon (or similar from
> > Qt) in gnome-shell 3.26, i.e. the legacy tray goes away without replacement?
> 
> Jein. The support for status icons is still in the underlying code, so
> extensions (like TopIcons and friends) can easily add them back. But there
> is indeed no replacement in gnome-shell itself, so status icons won't show
> up anywhere by default.

Will there be some code (e.g. in Gtk+) to detect whether the GtkStatusIcon can be displayed? Maybe one of
gboolean	gtk_status_icon_get_visible ()
gboolean	gtk_status_icon_is_embedded ()
would be suitable, or making gtk_status_icon_new() return NULL, I don't know. Applications need a way to detect the missing tray icon support instead of failing silently.

PS: I guess this is the wrong place to discuss. Where should that discussion go instead?

(In reply to Christian Stadelmann from comment #82)
> Will there be some code (e.g. in Gtk+) to detect whether the GtkStatusIcon
> can be displayed? Maybe one of
> gboolean	gtk_status_icon_get_visible ()
> gboolean	gtk_status_icon_is_embedded ()
> would be suitable, or making gtk_status_icon_new() return NULL, I don't
> know. Applications need a way to detect the missing tray icon support
> instead of failing silently.
> 
> PS: I guess this is the wrong place to discuss. Where should that discussion
> go instead?

https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B

(In reply to Jeremy Bicha from comment #83)
> (In reply to Christian Stadelmann from comment #82)
> > Will there be some code (e.g. in Gtk+) to detect whether the GtkStatusIcon
> > can be displayed?
> 
> https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B

Thanks, see https://bugzilla.gnome.org/show_bug.cgi?id=786517

For what it's worth, I've filed a fix for the topIcon extension to adjust to the legacy tray removal. After applying an additional gnome-shell fix in bug 786526, this should allow users to use the extension again without any changes in behavior or functionality.

[0] https://gist.github.com/fmuellner/e1aaec3169990fa7b7bd95da4e0a915a
[1] https://bugzilla.gnome.org/show_bug.cgi?id=786526