| Summary: | new notifications briefly show above lock screen while lock is engaged | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Timothy Pearson <kb9vqf> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | CONFIRMED --- | ||
| Severity: | enhancement | CC: | albator78, bugwatch, slavek.banko |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Attachments: | Closes all tooltips when kscreensaver starts | ||
|
Description
Timothy Pearson
2012-07-01 16:51:34 CDT
Note that this is a problem in the TDE compositor; specifically it is handling the overlay of tooltips incorrectly by raising them over the lock window. The patch pushed a while back in GIT hash 7295893a may provide a mechanism for fixing this bug. *** Bug 1122 has been marked as a duplicate of this bug. *** Hello, when you say "the TDE compositor is active", does that means that the "Enable the Trinity window composition manager" checkbox is checked ? Because the tooltip problem happens to me even when it is unchecked. I've juste done the following test: - open an LXDE session. - run firefox - make any tooltip appear (in my case, I put the cursor on a bookmark from the bookmark toolbar). The tooltip remains on screen indefinitely (no timeout), this is normal. => Until here, TDE is not involved at all. Then, from a remote shell (ssh), while the tooltip is still displayed, run: $ DISPLAY=:0.0 /opt/trinity/bin/kdesktop_lock Guess what ? The tooltip remains on top of the TDE screensaver. From my ignorant point of view, it's not a low-level QT or kde library problem. It's "just" that the "blank screen" is not "on top of everything else". Created attachment 783 [details] Closes all tooltips when kscreensaver starts Hello, the attached patch is a proposal to fix this bug. Since we have troubles hiding tooltips, it simply closes all of them when the kscreensaver starts. It is based on the analysis in the following page: http://shallowsky.com/blog/tags/tooltips/ It seems to work OK on my test 3.5.13-sru. Nice. Unfortunately, the problem remains that this solution does not prevent to display of new tooltips - for example, bubbles for incoming messages from Kopete, information about new mails from Korn, etc. I did not notice that "notification popup" were also affected by this, I only saw the classic tooltips ! Do you mean that we have this bug too ? https://bugs.kde.org/show_bug.cgi?id=179924 I will look how they fixed it in KDE 4.9 and see if it can be backported in TDE. The real issue is in Xorg and the compositor, believe it or not. Xorg and the compositor have a very hard time knowing whether or not tooltips, notification popups, or the lock screen should be shown on top. All of these windows are classified in such a way that they are all requesting top-level visibility at all times. I will get around to this report eventually, don't worry. ;-) The solution is not to close popups, notifications, etc., the solution is to stack the windows properly in the compositing manager. Tim It turns out that Francois was correct, but only because the structure of Xorg does not allow for any management of override redirect windows such as those used by tooltips and notifications. I have pushed a patch in GIT hash 553923b that not only closes all such windows on lock start, but also actively prevents any such windows from being displayed while the lock is active. While this behaviour may seem destructive at first, when the actual function of notifications and tooltips is considered it makes sense; i.e. why should the notification/tooltip be shown under the lock dialog (hidden) vs. not being shown at all (destroyed)? Thanks for reporting, and for finding a viable workaround! Please test and verify that the bug is solved and also that it does not have unintended side-effects, then mark this bug report as RESOLVED FIXED if everything checks out OK. Thanks! Tim I have one complication - bubble for incoming messages from Kopete, which otherwise does not close automatically. User due to 'destroy' bubbles can easily overlook that the sender (or more senders) wrote. Additionally, was not openned next bubbles announcing messages from the same sender, until the user will not read message with 'destroyed' bubble - very annoying. I do not know if there are any other notices that otherwise remain open - for which their 'destruction' is also wrong? It's still 'ugly hack', not 'nice solution'. Otherwise, I tested the patch in 3.5.13-sru and work as designed. I now tested: with bubbles from Kopete it's even worse - after 'destroying' first bubble are not showed none at all, as long as the user does not notice the first missed message - the first 'destroyed' bubble. The only "nice solution" I can think of *requires* the use of a compositor and non-standard X11 atom hints. There is simply no way to get Xorg itself to do what we want here, which is to keep a specific window above everything else at all times. And no, "override redirect" won't work here, as the offending tooltips/notifications use "override redirect" themselves, resulting in stacking above the lock screen if they are displayed while the lock is active. "Override redirect" causes other problems as well, including forcing use of the ugly unmanaged (and undecorated!) lock windows that have become so characteristic of Linux. Applications should not respond to the unmapping of their tooltips/notifications by preventing any more from being displayed; if they do then that application has a bug. (In reply to comment #12) > I now tested: with bubbles from Kopete it's even worse - after 'destroying' > first bubble are not showed none at all, as long as the user does not notice > the first missed message - the first 'destroyed' bubble. Can you try this? In kdesktop/lock/main.cc, comment out line 99: XDestroyWindow(create_event.display, create_event.window); Then rebuild/reinstall tdebase, and log out/log in before testing again to see if this change has worked around the "bubble not appearing" problem. If it has, we may need to live with the notification appearing on the user's screen for an instant before it is unmapped. If it does not fix the problem, Kopete has a bug that needs to be fixed. Thanks! Tim I have pushed a better solution into GIT in hash 57f5c06. This solution hides all of the offending windows on lock start, and restores them on lock exit. It also intercepts new mapped windows and hides them while the lock is active. The main problem with this solution is that the new window is usually visible on-screen for a fraction of a second. Given the serious disruption the previous hack caused, this compromise is needed. I would however like to leave this bug open to see if a solution can be found which prevents display of the override-redirect window at all, possibly by lowering the window in the CreateNotify handler. Let me know if the updated lock screen causes any other problems! Tim Fabulous. I tried to add also 57f5c06 into v3.5.13-sru and it looks very good. These patches are now candidates for incorporate into v3.5.13-sru prior to release 3.5.13.1. (In reply to comment #15) > I would however like to leave this bug open to see if a solution can be found > which prevents display of the override-redirect window at all, possibly by > lowering the window in the CreateNotify handler. As far as I can tell there is no mechanism available in X11 to fix this glitch. I have tried to minimize the time spent on-screen in GIT with XFlush, but every now and then a new notification will show on-screen for a fraction of a second before being hidden. I'm going to leave this bug open for tracking (under a different name) in case someone else discovers a suitable hack to fix this glitch. |