Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

Difference in Response times between BrowserSetText and BrowserTypeKeys

Difference in Response times between BrowserSetText and BrowserTypeKeys

Since the release of Silk Performer 9.5, various functions within the browser driven load testing approach are replayed using Windows API-level events as opposed to the prior method of replaying using JavaScript events. This is referred to as Native Replay and its purpose is to provide the end user with an even more reliable replay experience. Native replay is enabled by default within Silk Performer and can be disabled by going to profile settings (Replay - Web (Browser Driven) > General > Input and enabling Legacy input mode or by inserting BrowserSetOption(BROWSER_OPT_LEGACY_INPUT_MODE, true) into the test script. 

With Legacy input mode disabled, the following functions are replayed with a native equivalent:

-          BrowserClick function is replayed as the BrowserNativeClick function

-          BrowserDoubleClick replayed as BrowserNativeDoubleClick

-          BrowserSetText and BrowserSetPassword replayed as the BrowserTypeKeys function

-          BrowserMouseMove function is replayed as BrowserNativeMouseMove

From the list above, it is noted that the BrowserSetText function is replayed as BrowserTypeKeys. With this, we might expect the response times returned for each function to be very similar - assuming they are being run against the same element and carry out the same action, i.e:

BrowserSetText("//input[@id='login-form:email']", "test123");
BrowserTypeKeys("//input[@id='login-form:email']", "test123");

This however is not the case. BrowserTypeKeys is faster than BrowserSetText and sometimes the difference is significant. The difference is caused by the differing actions these functions make. When replaying, BrowserSetText makes a BrowserGetText call first to see if it has to clear the contents of the text control before entering the keystrokes defined in the function. This action takes a few milliseconds. BrowserTypeKeys does not care about the contents of the text box and just adds the extra letters in regardless of its current value – so it is faster.

Both functions still use Windows api events to input text.

As detailed earlier, if legacy input mode is enabled in the active profile settings or via the BrowserSetOption function, then BrowserSetText does not replay as BrowserTypeKeys – it does not use the windows api to enter keystrokes. Instead it uses JavaScript event to update the textContents property value. This mechanism is extremely fast, faster than the others; but some text boxes don’t allow it so it won’t be suitable in all circumstances. Here is the same scenario with legacy input mode:

BrowserSetText("//input[@name='name']", "demonstration"); 

Therefore, if speed is the main concern, then BrowserSetText with legacy input mode enabled would be the fastest means of entering text into the field but it can be unreliable, which is the reason why, by default, legacy mode is disabled.


Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
1 of 1
Last update:
‎2016-10-27 20:41
Updated by:
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.