Replaying browser-driven scripts - Limitations

Micro Focus Expert
Micro Focus Expert
0 0 840

Silk Performer uses Internet Explorer to record browser-driven scripts. To replay these scripts, you can use either Internet Explorer, Firefox, or Chrome.

Although these browsers basically resemble each other, they can behave quite differently in a variety of circumstances. The varying behavior can be particularly obvious when replaying the very same script with different browsers.

Below you can find a number of areas where you might encounter differences or issues. Note that many of the described issues are corner cases. The limitations heavily depend on your specific use case and on the application under test, including the underlying frameworks. Therefore, it is not possible to describe every potential limitation in every detail. If you encounter a specific limitation and need more information, contact SupportLine.


When interacting with a web server, a user might need to authenticate himself. Before the server sends the requested resource it asks the browser for authentication. The browser in turn typically displays a pop-up window to ask the user for their credentials. You can specify these credentials by scripting the BDL function BrowserSetAuthentication(). When executing a load test with Internet Explorer, the specified credentials are passed automatically to the virtual users. However, this is not supported by the WebDriver-based browsers Chrome and Firefox.

Client certificates

Instead of user credentials, some web servers demand a client certificate to verify the authenticity of the user interaction with the application. Usually, a user has a personal client certificate, which is stored in a secure place. When the server requests a client certificate from the browser, the browser asks the user, which client certificate (if there are more than one) to use for the authenticity check. Internet Explorer supports this scenario when executing load test scripts - you can specify a client certificate using the BDL function BrowserSetCertificate(). However, the WebDriver-based browsers Chrome and Firefox do not support such a scenario.

Mouse clicks

When replaying scripts, mouse clicks are processed differently in different browsers. Or more specifically: The application under test receives different click events, depending on the used browser. For example: Replaying a double-click, raises a click and a double-click event in Internet Explorer and Firefox - this is the default behavior. But replaying a double-click in Chrome, raises just a double-click event.

Another example: When replaying a script in Chrome, the right-click event fails when the center of the clicked element is not visible. But in Internet Explorer and Firefox, the right-click event works flawlessly, even if the center of the clicked element is obscured.

Here are the capabilities and limitations in detail:

  • In Chrome, left-clicks work as expected.
  • In Chrome, click coordinates work as expected (for left-, right-, and double-clicks).

The following issues are due to a flawed WebDriver implementation within the different browsers. They may be fixed in future versions of the browsers:

  • In Chrome, right-clicks only work, when the center of the element is visible.
  • In Chrome, by default, a double-click is performed on the center of a clicked element. This is also true, when the element is obscured by another element.
  • In IE and Firefox, a double-click raises a click and a double-click, but in Chrome, a double-click raises just a double-click.
  • In IE, a Dom Click fallback may click a wrong button.
  • When using a native click function (for example BrowserNativeClick) and specifying coordinates in the script, the TrueLog shows these coordinates, which might be misleading.
  • When using a native click function (for example BrowserNativeClick) and no coordinates are specified, the TrueLog marks the center of the element. The actual click position might differ if the center of the element has been obscured by another element.

Key strokes

Using key strokes within browsers also results in varying behavior. For example: When the cursor is placed within a text field within Internet Explorer and you press the Esc key, everything you have typed so far is being removed. Pressing the Esc key in the other browsers has no effect. Another example is that Firefox and Chrome do not differentiate between the Return key and the Enter key on the numpad, while Internet Explorer does.

Here are the limitations in detail:

  • In IE, when the cursor is placed within a text field and you press the Esc key, everything you have typed so far is being removed. Pressing the Esc key in Firefox or Chrome has no effect.
  • Another special behavior in IE when pressing the Esc key: When you type text into a text field, then temporarily remove the focus from the field and activate it again to continue typing, pressing the Esc key removes only those characters that have been typed since the last focus change.
  • In Firefox and Chrome, pressing the Insert key has no effect.
  • Pressing the Page up key when a text field has focus, results in different behavior in the different browsers. Use the Home key instead.
    • IE moves the cursor to the beginning of the text field.
    • Chrome moves the cursor to the beginning of multi-line text fields. In single-line text fields, pressing Page up has no effect.
    • In Firefox, pressing Page up has no effect, neither in single-line nor in multi-line text fields.
  • Firefox and Chrome do not differentiate between the keys Enter and Numpad Enter.
  • When using modifier keys with single clicks, key-down events are not fired for the modifier keys.
  • When using modifier keys with double clicks, no key events are fired - neither key-down nor key-up events.
  • Many special keys can only be used within text fields. They are not registered by other DOM elements. This is true for all numpad and modifier (Shift, Ctrl, Alt) keys.


A browser might use an element attribute that the other browsers do not offer. For example: Internet Explorer uses spellcheck as a generic attribute that exists for every element, while Chrome and Firefox only use the attribute when it is explicitly specified. Since Internet Explorer is used for recording the script, this results in an error when the script is replayed with Chrome or Firefox.

New Windows

When your application under test uses a number of short-lived pop-up windows, this might result in unstable behavior. Here is a real-world example that might cause issues: You click a link that opens a pop-up window. This window immediately triggers another window to open, and then it closes again. When you use Firefox or Chrome, the window might be missed during replay and the BDL function BrowserWaitForNewWindow() will time out. A possible workaround is to use the custom function BrowserWaitForNewWindowWithLocator(), which is located in the BrowserAPI.bdh.

Invalid URLs

When you navigate to an invalid URL, Internet Explorer raises an error, while Chrome and Firefox do not. This can be problematic when monitoring a URL. The monitor will never raise an error, although the URL cannot be reached. For such a case, it can be useful to add a verification function to your script


Due to the diverse replay technologies and the different architectures of the applications under test, some measures might be missing. For example: Some traffic might not be considered, because the application under test uses redirects or iframes.

Here are the limitations in detail:

  • When resources are loaded from different hosts, some data might not be available due to the Same-Origin-Policy.
  • Some traffic might be missed due to iframes or redirects.
  • Web worker AJAX requests are not tracked.
  • iFrame performance data that is collected in the beforeunload handler is only available for the same origin iFrames.
  • Data from inactive windows is not collected until the windows are activated.
  • iFrames can show up twice in the TrueLog, depending on the used browser and involved hosts.
  • The measure First paint is available for IE only.

Dialog handling

When you use Firefox or Chrome to replay scripts, only JavaScript dialogs (alert, prompt, and confirm boxes) can be handled. Native dialogs, like the file save or file open dialog, are not supported.

The following table shows which dialogs are supported by which browsers:

JavaScript dialogs

supported in all browsers

Print dialog

not supported

File Save & File Open dialog

supported in Internet Explorer

Modal windows and modeless windows (HTML dialogs) *

supported in Internet Explorer

 * HTML dialogs display as windows. Note that modal and modeless windows are a specific feature of Internet Explorer, hence they are only supported in Internet Explorer.

Here are the limitations in detail:

  • As WebDriver cannot retrieve the title of JavaScript dialogs, the dialogs are processed in the same order in which they were added with BrowserDlgSetButton and BrowserDlgSetText.
  • As WebDriver cannot retrieve the labels of buttons, it is necessary to specify the OK and Cancel button (case insensitive) in BrowserDlgSetButton. Priliminary localization has been added for Chinese, Japanese, German, French, Portuguese, Spanish, and Russion, so OK and Cancel buttons can also be specified in these languages. All other button labels will be ignored and the dialog will not be interacted with. Instead, a warning will be logged in an agent log.
  • As JavaScript prompts can only contain one text field, the position parameter of BrowserDlgSetText is completely ignored.

Compatibility mode

Scripts that are created using Silk Performer 18.5 or an earlier version, use a different replay compatibility mode. You can set the compatibility mode in the profile settings or by using the BDL function BrowserReplayCompatibility.

In the past, locators used to be tailored to Internet Explorer, because it was the only supported browser. Thus, the locators used in these older scripts might cause replay issues.

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.