Bug 1104664

Summary:	when going to offline mode, evolution shows sync dialog window on top of last opened main window, not actual window
Product:	Red Hat Enterprise Linux 7	Reporter:	David Jaša <djasa>
Component:	evolution	Assignee:	Matthew Barnes <mbarnes>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	djasa, fidencio, mcrha, tpelka
Target Milestone:	rc
Target Release:	7.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	810460	Environment:
Last Closed:	2016-01-14 15:29:47 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	810460
Bug Blocks:

Description David Jaša 2014-06-04 13:11:48 UTC

this bug affects Evolution in RHEL 7.0 as well
evolution-3.8.5-21.el7.1.x86_64


+++ This bug was initially created as a clone of Bug #810460 +++

Description of problem:
when going to offline mode, evolution shows sync dialog window on top of last opened main window, not actual window

Version-Release number of selected component (if applicable):
evolution-2.28.3-24.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. open evolution
2. open another window (ctrl + shift + W), move it to some other desktop
3. in the first window, hit "offline" icon
  
Actual results:
  * a dialog asking if Evo should synchronize mail or not pops on top of second, not visible window
  * a dialog window is not highlighted in window list

Expected results:
  * dialog window pops on top of active window
  * dialog window is highlighted

Additional info:

--- Additional comment from Milan Crha on 2012-04-06 14:01:35 CEST ---

Thanks for a bug report. That "sync dialog window", is it the one where you are asked whether you want to synchronize message locally, before evolution gets fully offline? I would expect it being shown on a monitor where it was invoked, but it's possible your window manager decided a different action.

--- Additional comment from RHEL Product and Program Management on 2012-07-10 08:35:27 CEST ---

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

--- Additional comment from RHEL Product and Program Management on 2012-07-11 01:09:10 CEST ---

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

--- Additional comment from RHEL Product and Program Management on 2012-12-14 08:08:02 CET ---

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

--- Additional comment from Milan Crha on 2013-06-11 19:40:27 CEST ---

FIxed by rebase.

--- Additional comment from errata-xmlrpc on 2013-11-21 06:04:46 CET ---

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-1540.html

Comment 1 Milan Crha 2014-06-05 18:30:10 UTC

(In reply to David Jaša from comment #0)
> --- Additional comment from Milan Crha on 2013-06-11 19:40:27 CEST ---
> 
> FIxed by rebase.

Hrm, there is no exact fix for this available. git master is also not affected, at least when using MATE desktop on Fedora, which makes me wonder whether it's not some regression of gnome-shell.

What is your gnome-shell version, please?

Comment 2 David Jaša 2014-06-05 18:47:44 UTC

(In reply to Milan Crha from comment #1)
> What is your gnome-shell version, please?

gnome-shell-3.8.4-31.el7.x86_64

Comment 3 Milan Crha 2014-06-06 07:27:30 UTC

(In reply to David Jaša from comment #0)
> this bug affects Evolution in RHEL 7.0 as well
> evolution-3.8.5-21.el7.1.x86_64

(In reply to David Jaša from comment #2)
> (In reply to Milan Crha from comment #1)
> gnome-shell-3.8.4-31.el7.x86_64

Weird, I have the same versions, but I cannot reproduce it, both in GNOME and GNOME Classic modes.

What I do:
a) run evolution as the first application after login (it starts maximized,
   but it doesn't seem to matter)
b) File->New Window
c) right-click title bar and choose "Move to Workspace Down" (it still lefts
   focus on the first workspace)
d) click the online/offline button in the status bar
   - the question is shown at the first (current) workspace
e) click the online/offline again, to get online
f) switch to the second workspace (Ctrl+Alt+Arrow-Down)
g) click the online/offline button in the status bar
   - the question is shown at the second (current) workspace

Comment 4 David Jaša 2014-06-06 13:32:25 UTC

my steps:
1) run evolution, switch to mail if in other view
2) open new calendar window by middle-clicking Calendar button
3) move calendar window to different desktop (or at least monitor)
4) in mail window, mark folder as read (or go offline as in original bug)
- the confirmation dialog appears on top of calendar window in both cases

I use gnome-shell in gnome-shell mode with just a few extensions (lock keys, Places, window list, system-monitor).

Comment 5 Milan Crha 2014-06-09 13:38:50 UTC

(In reply to David Jaša from comment #4)
> 3) move calendar window to different desktop (or at least monitor)

No, I'm still not able to reproduce this. Maybe the difference is with multiple monitors, I move only between desktops (workspaces in gnome-shell's terminology)?

> I use gnome-shell in gnome-shell mode with just a few extensions (lock keys,
> Places, window list, system-monitor).

I cannot find "lock keys" extension, could you:
   $ rpm -qa | grep gnome-shell | sort
please?

Comment 6 David Jaša 2014-07-07 13:19:33 UTC

(In reply to Milan Crha from comment #5)
> (In reply to David Jaša from comment #4)
> > 3) move calendar window to different desktop (or at least monitor)
> 
> No, I'm still not able to reproduce this. Maybe the difference is with
> multiple monitors, I move only between desktops (workspaces in gnome-shell's
> terminology)?
> 

I indeed use 2 monitors and I frequently disconnect one of them. I found out that I see the bug only when it is running for a long time, not after a fresh start so maybe display reconfiguration takes some role.

> > I use gnome-shell in gnome-shell mode with just a few extensions (lock keys,
> > Places, window list, system-monitor).
> 
> I cannot find "lock keys" extension, could you:
>    $ rpm -qa | grep gnome-shell | sort
> please?

It is from extensions.gnome.org.

Comment 7 Milan Crha 2014-07-07 13:31:23 UTC

(In reply to David Jaša from comment #6)
> I indeed use 2 monitors and I frequently disconnect one of them. I found out
> that I see the bug only when it is running for a long time, not after a
> fresh start so maybe display reconfiguration takes some role.

Then I'd guess the issue lies lower in the stack, either gnome-shell (as a window manager), or gtk3 itself.

Comment 9 Milan Crha 2015-06-02 12:31:02 UTC

I just checked the code and the Synchronize/Do Not Synchronize question dialog takes as its parent the active window, as reported by gtk_application_get_windows() - the first member of that returned list. After that a gtk_dialog_run() is called. I do not see any place where we would be able to influence on which Desktop/Workplace the window should be shown other than the 'parent' being set to the right one.

Comment 10 Milan Crha 2016-01-14 14:52:56 UTC

David, could you retest with 7.2, what the gtk+ rebase did with this, please? I was unable to reproduce even before.

Comment 11 David Jaša 2016-01-14 15:29:47 UTC

I encountered it only once in recent months (when 7.2 release was close) but I couldn't reproduce it subsequently. Let's close as CURRENTRELEASE and reopen if it resurfaces again.