When recording a script, typically KITE sets the completion condition to use the number of Browser Ready cycles it receives from Internet Explorer. However, if KITE detects asynchronous activity it may instead set the completion condition to be 1000 msec of HTTP inactivity.
This help topic provides an overview of the most commonly used completion events. When recording a Transaction Perspective script KITE will attempt to set an appropriate completion event for each action (page) within the script. However, certain AJAX/Web 2.0-based web sites or other rich Internet applications may require modifications to the recorded script in order to be more robust.
|Watch a short video about Completion Events|
This is the most common completion event, which checks for browser download cycles by default (i.e., the page reaches a ReadyState according to Internet Explorer). One download cycle (indicated by the Count parameter shown above) is essentially when a page has finished loading and it says “Done” in the browser status bar. Some dynamic pages will load content after one download cycle, which is why you sometimes see more than one download cycle recorded.
|Watch a short video about Browser Completion Events|
Note on Firefox and Chrome
Browser-ReadyState is not supported for playback on Firefox and Chrome. This completion event is automatically converted to Timer - 6 seconds on Firefox and HTTP Messages: Inactivity - 3 seconds on Chrome.
Browser completion event with additional conditions
The Browser completion event allows for compound completion conditions, most commonly one download cycle plus a WaitFor event. With a WaitFor event, you can configure a completion event that first checks for a download cycle, then waits for the addition, removal, pattern match, or pattern mismatch of a given DOM element. The script will periodically check if the WaitFor condition is met, as defined by the Cycle(sec) parameter. The AddElement and PatternMatch conditions are more commonly used; these conditions wait for the addition of a particular element to the downloaded page, or wait for a pattern match against a specific element’s attribute value (respectively).
Most commonly used to WaitFor the addition , removal , pattern match , or pattern mismatch of a given DOM element. The target DOM element is identified by a tag type, relative page index, and attribute name/value pair. This completion event looks for a specific DOM element to be loaded/rendered and is not affected by how many download cycles have occurred.
Note on Firefox and Chrome
The following completion events are not supported for playback on Firefox and Chrome:
These completion events are automatically converted to Timer - 6 seconds on Firefox and HTTP Messages: Inactivity - 3 seconds on Chrome.
|Watch a short video about how to use the WaitFor completion event to look for a specific DOM element to be changed.|
This type of completion event checks the HTTP messages when a page is downloaded.
The most common use of this completion event is the Inactivity timer, which will check for a lack of HTTP message downloads for a specific duration (for example, Event: Inactivity – 1000 msec).
This completion event can also count the number of HTTP messages received, and the completion condition will be considered met once the specific number of HTTP messages as been seen.
The completion condition can also be met when a Named object has been downloaded (for example, when a specific image file has been downloaded).
|Watch a short video about how to configure HTTP Messages to help with dynamic page completion events.|
This completion event should only be used if all others fail.
This completion event is a timer which begins once all of the script’s actions for the page have been executed. The potential issue with this completion event is that it may not wait long enough for all content to download depending on the timer duration.