Bug 731178 - Button not responding deterministically to automated clicks
Button not responding deterministically to automated clicks
Status: NEW
Product: RHQ Project
Classification: Other
Component: Tests (Show other bugs)
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
: TestBlocker
Depends On:
  Show dependency treegraph
Reported: 2011-08-16 16:30 EDT by dgao
Modified: 2011-08-17 11:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.