This occurs when I try save Draft.

Please see my [1] issue

[1] https://bugzilla.redhat.com/show_bug.cgi?id=805923

Thanks for a bug report. If the saving is stuck on the draft saving, then it makes sense evolution doesn't quit. Thus the wrong part can be the issue with draft saving. I updated bug #805923 with request for more information already. If you could also get backtrace of the stuck evolution, then it'll help to see what it is waiting for.

You can generate the backtrace as this:
   $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt
where PID is a process ID of running evolution. Make sure you have installed debuginfo packages for at least gtkhtml3, evolution-data-server, evolution and any other evolution package you use, and that they are of the same version as the binary package. You can check that with command like this:
   $ rpm -qa | grep evolution | sort

I couldn't find debuginfo packages for evolution, evolution-mapi, gtkhtml3. what am I doing wrong?

[mikhail@telecon17l ~]$ sudo yum install evolution-data-server-debuginfo evolution-debuginfo evolution-mapi-debuginfo gtkhtml3-debuginfo
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Install Process
No package evolution-debuginfo available.
No package evolution-mapi-debuginfo available.
No package gtkhtml3-debuginfo available.
Nothing to do

When I do `gdb --batch --ex "t a a bt" -pid=12325 &>/tmp/bt.txt`
in bt.txt writed SELinux warning:
warning: the SELinux boolean 'deny_ptrace' is enabled, you can disable this process attach protection by: (gdb) shell sudo setsebool deny_ptrace=0
ptrace: Permission denied.

The debug-info packages are in a different repository. Try to add to the "yum install" also this parameter:
   --enablerepo=*debuginfo

Ah, they might change the policy recently. Run as root:
   $ setsebool deny_ptrace=0
and then the command should work.

Created attachment 572935 [details]
backtrace

Thanks for the update. I see from the backtrace that the application does basically nothing, it's in idle. It seems like there left a window in the background, which prevents the application to stop - most likely the composer window. The good news is that the composer is not stuck with saving operation.

I tried to reproduce this on my F17 installation and it works as expected to me. I tried these steps:
a) run evolution from terminal in a mailer view
b) compose a new message in an evolution-mapi account
c) instead of Send I pressed Save as Draft on the message's toolbar
d) close composer, close evolution
Now I see terminal prompt, indicating evolution was closed.

Then I added a new message into On This Computer/Outbox, which is causing the question about Cancel/Quit on evolution's close for you (the folder should be empty on evolution's close), but even with that I'm asked, and answering "Quit" quits evolution. The thing is that I'm always asked, even when I close evolution before the composer window, then on composer's close I'm asked to Cancel/Quit, which is quite funny, because Cancel means "return back to composer" where I cannot change anything. I also set up a remote folder as the Drafts folder for the mapi account, but except of slower saving of draft it doesn't do anything differently - everything works the same as described above.

Created attachment 574145 [details]
yet another backtrace

Created attachment 574146 [details]
yet another backtrace after some time

Created attachment 574147 [details]
yet another backtrace from another machine

add backtrace which are obtained when I using evolution-ews.

This is another case not related to the saving draft.

Thanks for the update. The first is waiting for e_ews_connection_update_items() in one thread. The other threads seem to be idle. The second looks similarly, only the function is shown in two threads. Finally the third does not do anything with ews, it is waiting in Thread 3 on a response from your IMAP+ server.

I miss good steps for a reproducer here, what I tried (see comment #8) worked as expected here.

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

Could you retry with evolution-ews-3.4.2-2, please? I just built it and added to updates-testing, couple minutes ago. It'll take few hours till the change is propagated to mirrors, but I guess it'll be available for testing tomorrow, the latest. Thanks in advance.

There is still no version of evolution-ews-3.4.2-2 :( Today, Xorg updated but as there was no evolution and no :(

The update have been marked for stable only recently, give it a day or two, till the changes are propagated to mirrors:
https://admin.fedoraproject.org/updates/FEDORA-2012-7850/

> I tried to reproduce this on my F17 installation and it works as expected to
> me. I tried these steps:
> a) run evolution from terminal in a mailer view
> b) compose a new message in an evolution-mapi account
> c) instead of Send I pressed Save as Draft on the message's toolbar
> d) close composer, close evolution
> Now I see terminal prompt, indicating evolution was closed.


https://docs.google.com/open?id=0B0nwzlfiB4aQZjhvLUE0QVRFRmM

If I press 'Save Draft' on popup windows which appear when I close composer windows without saving or sending mail then first problem described here in first message is occurs.

The video shows that after selecting Emoticon the new mail composer stops receiving input from keyboard, and apparently from mouse as well. This is fixed in gtkhtml3-4.4.2-3, currently built for bug #829915, and the fix is also part of gtkhtml3-4.4.3, which is to be released the next Monday, June 18th.

I thought this is unrelated to this bug report, or did I just misunderstand the issue being discussed here?

Sorry this is my mistake, please see another video: https://docs.google.com/open?id=0B0nwzlfiB4aQYXgwOHpYWnJ2YWc

I see. I can reproduce this even without evolution-ews, thus I'm moving it upstream as [1]. Feel free to CC there yourself, as any further updates regarding this sub-issue will be done there.

With respect of e_ews_connection_update_items(), could you retest this with 3.4.3 release, please? I finished it approximately an hour ago, the update should be available in updates-testing within a day or so. There were done multiple fixes in evolution-ews too, and even they were not directly related to this, then it's possible they could influence behaviour of this as well. Thanks in advance.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=678304

I didn't see this in your reports for the past week or so, maybe it's finally fixed, and this bug can be closed? (the e_ews_connection_update_items() issue.)

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.