Bug 731178 - Button not responding deterministically to automated clicks
Summary: Button not responding deterministically to automated clicks
Keywords:
Status: NEW
Alias: None
Product: RHQ Project
Classification: Other
Component: Tests
Version: 4.2
Hardware: All
OS: All
medium
medium
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-16 20:30 UTC by dgao
Modified: 2022-03-31 04:28 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description dgao 2011-08-16 20:30:56 UTC
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 20:33:41 UTC
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 14:57:39 UTC
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.