Bug 785828

Summary:	Startup Applications GUI does not submit change immediately, has delay of 3-4 seconds before taking effect
Product:	Red Hat Enterprise Linux 6	Reporter:	BJ Walker <bwalker>
Component:	gnome-session	Assignee:	Ray Strode [halfline] <rstrode>
Status:	CLOSED ERRATA	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	low	Docs Contact:
Priority:	low
Version:	6.2	CC:	pedrogfrancisco, tlavigne, tpelka
Target Milestone:	rc
Target Release:	6.5
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:	gnome-session-2.28.0-20.el6	Doc Type:	Bug Fix
Doc Text:	Cause: incorrect clean up of resources at shutdown Consequence: changes are queued on a 2 second timeout. if the dialog is closed before 2 seconds after making a change, the changes would fail to be committed. Fix: explicitly destroy the dialog on shutdown, so it's dispose handler runs to commit any pending changes Result: users can enable/disable Additional Startup Programs and quickly close the dialog without losing whatever change they just made	Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-10-14 08:11:32 UTC	Type:	---
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:
Bug Blocks:	782183, 1056252

Description BJ Walker 2012-01-30 17:51:21 UTC

Description of problem:
When opening the "Startup Applications" GUI, and either deselecting or selecting a checkbox next to a specific field, if you click close immediately the change does not take effect.  In order to get the change to be persistent you must wait 3-4 seconds before hitting close.

Version-Release number of selected component (if applicable):
gnome-settings-daemon-2.28.2-11.el6.i686

How reproducible:
100% of the time.

Steps to Reproduce:
1. Open "Startup Applications" GUI
2. Make change and click close immediately
3. Open "Startup Applications" GUI and see the change did not take effect
  
Actual results:
The changes are not persistent after close.

Expected results:
After making a change and hitting close the change should be persistent, instead you must wait a delayed amount of time before hitting close.

Additional info:
Suggestion to grey out close button until change has occurred or to delay the ability to exit until all changes have taken effect.

Comment 3 RHEL Program Management 2012-05-03 04:42:59 UTC

Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 5 RHEL Program Management 2012-12-14 06:55:05 UTC

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.

Comment 9 ralacroix 2013-06-20 18:00:09 UTC

Bug 812647 appears to be a duplicate of this bug.

Comment 10 RHEL Program Management 2013-10-14 00:49:30 UTC

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 15 errata-xmlrpc 2014-10-14 08:11:32 UTC

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/RHBA-2014-1585.html