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. This can also result in different behavior, 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 and rarely occur. Also note that 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 replaying scripts, mouse clicks are processed differently in different browsers. Or in other words: 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.
Here is 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.
Using key strokes within browsers also results in different 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.
A browser might use an element attribute that the other browsers do not use. 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.
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. A possible workaround is to use the custom function BrowserWaitForNewWindowWithLocator, which is located in the BrowserAPI.bdh.
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.
When you use Firefox or Chrome to replay scripts, only JavaScript alerts and prompts can be handled. Native dialogs, like the file save or file open dialog, are not supported.
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.