After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 368041 - Password entry dialog appears beneath other windows
Password entry dialog appears beneath other windows
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
2.8.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
evolution[passwords]
: 394113 464027 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-10-31 01:45 UTC by Sam Morris
Modified: 2012-06-10 15:15 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
Potential solution (944 bytes, patch)
2007-12-08 16:32 UTC, Ted Percival
rejected Details | Review

Description Sam Morris 2006-10-31 01:45:46 UTC
Please describe the problem:
It is possible for the password entry dialog to appear beneath other windows. Since the dialog does not appear in the Window Selector, it can be very hard to find.

This is frustrating because actions in the Evolution UI depend on correct entry of the password, but there is no link between the Evolution window and the password entry dialog, and no easy way to find it once it has appeared and gotten lost beneath another program's windows.

Steps to reproduce:
1. Launch evolution
2. Before the password entry dialog box appears switch to another program on another workspace
3. Wait a few seconds; the password entry dialog box appears beneath the program you switched to


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Gilles Dartiguelongue 2007-04-20 15:18:12 UTC
I can confirm this is really frustrating sometimes.
Comment 2 Ted Percival 2007-12-08 16:32:53 UTC
Created attachment 100593 [details] [review]
Potential solution

This patch makes password dialogs transient for the main window (unless another parent was specified).
Comment 3 Srinivasa Ragavan 2007-12-09 18:55:45 UTC
Ted, I dont think this is a right fix IMO. We should get the top level widget in specific cases and pass it to this.
Comment 4 Ted Percival 2007-12-10 02:13:10 UTC
Thanks for the review Srinivasa.

It would be nice if all the callers passed through the GtkWindow* that they expect the dialog to be transient for, I was originally aiming to do that but got lost in the zoo amongst the Camels and Bonobos.

Instead I decided to ensure that, as a fallback, password dialogs are always transient for a top-level window. It's never nice for a password dialog to get lost without a panel button.

So I agree that the best solution to this is for the parent window to be passed in, but in addition to that it should also be the case that no password window is without a parent - which the patch ensures.
Comment 5 Srinivasa Ragavan 2007-12-10 06:57:11 UTC
Ted, if you need any help let me know. AFAIK, a lot of plugin codes introduce this. We need to tackle this on a issue by issue basis. We can chat on #evolution and I can help you the best possible extend to explain the code flow, if you can get me the situations. I hope that we would fix it the right way. Thanks.
Comment 6 Milan Crha 2008-03-17 16:16:49 UTC
*** Bug 464027 has been marked as a duplicate of this bug. ***
Comment 7 Milan Crha 2008-03-17 16:17:31 UTC
*** Bug 394113 has been marked as a duplicate of this bug. ***
Comment 8 Matthew Barnes 2012-06-10 15:15:52 UTC
This is fixed in Evolution 3.5.3.

Password prompts are now system modal and are handled by a D-Bus service rather than by Evolution itself.