Bug 731178

Summary:	Button not responding deterministically to automated clicks
Product:	[Other] RHQ Project	Reporter:	dgao
Component:	Tests	Assignee:	RHQ Project Maintainer <rhq-maint>
Status:	NEW ---	QA Contact:	Mike Foley <mfoley>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.2	CC:	hrupp, mfoley
Target Milestone:	---	Keywords:	TestBlocker
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Description dgao 2011-08-16 16:30:56 EDT

There are components in the UI that does not respond well to automated clicks. The most recent example being the "right" button in between available and added resources inside compatible groups create wizard. 

This is a long outstanding issue, and unfortunately I have yet to discover a functional workaround for this issue. The best I did in the past is to sprinkle sleep statements right before clicking a problematic component and hope the extra time would alleviate the issue. From my experience, this only works about 25%-50% of the time. 

Another observation is that the probability of the button actually responding decreases as the system become more stressful.

As previously discussed with dev, it seems like every smartGWT component have an inherit "timer" that switches between "not-ready" and "ready" state. If any action is committed during the "not-ready" state, the request gets dropped onto the floor. This could be related to the issue and plausibly explain why when the system it stressed, it takes longer to switch a component from not-ready to ready state.

Comment 1 Mike Foley 2011-08-16 16:33:41 EDT

there are a set of ui sporadic issues manifested by "quick clicking" ... that this may be related to.  dev is working on this right now.

Comment 2 Mike Foley 2011-08-17 10:57:39 EDT

not solvable by ui stability effort.  does not effect customers.  blocks testpoints in group membership (and possibly other areas where button enabling/disabling).  workaround could be to use the add all.  or programmatically use sleeps in testcode.  possibly encapsulate polling for component readiness in some common method.