How to display a website in a separate webview
The Custom widget normally displays a URL inside an iFrame, so the website is subject to the usual embedding restrictions: many sites refuse to be framed, and a sandboxed frame limits what the page can do. How to Embed External Content covers that route and its troubleshooting.
With Use separate webview, the device opens the URL in its own native webview instead, placed over the area of the widget. The site loads as a standalone page rather than an embedded one, so iFrame restrictions such as X-Frame-Options do not apply. You can also run your own JavaScript on the loaded page, for example to accept a cookie consent banner.
Related articles
- How to Embed External Content
- How to Embed Password-Protected External Content
- How to Embed External Content Using Alternative Methods
Supported players
| Player | Minimum version |
|---|---|
| Windows | 4.0.739 |
| Android | 5.0.774 |
| BrightSign (JsCore) | 4.1.1660 |
The table above is the minimum for the separate webview itself. Two later additions have their own minimums, so a player that meets the versions above does not necessarily have them:
| Capability | Windows | Android | BrightSign (JsCore) |
|---|---|---|---|
| Keeping page state when hidden and shown, and ordering between native elements | 5.0.650 | 5.0.830 | not yet available |
| Restricting which addresses may be opened | 5.0.650 | not yet released | not yet released |
LG and Samsung players do not support the separate webview. For content that plays on those devices, leave the option off and use the iFrame route or one of the alternative embedding methods.
Set up the widget
- Add a Custom widget to the page, then set its size and position. The webview covers this area on the device.
- In the Text section, set Content type to URL and enter the website address in the URL field.
- Turn on Use separate webview.
- Optionally, enter a script in Script on load up, described in the next section. On Android, you can also set Separate player z-index (0–999) to change the layer position of the webview; other players ignore this setting.
- Save the content and assign it to a device running a supported player.
When Use separate webview is on, the settings that only apply to iFrame embedding are hidden: Interactive, Allow microphone, Allow camera, Send screen parameters, Same origin, and Contains audio.
Run a script on the website
Script on load up takes plain JavaScript that runs on the website after the page loads. On Windows and Android, it runs again after every page load inside the webview, including redirects, so it also reaches the page that finally appears.
A common use is dismissing a cookie consent banner. This example clicks a consent button; replace #accept-cookies with the selector of the button on your website:
document.querySelector('#accept-cookies')?.click();
The script can only act on elements that are on the page when it runs. If the website changes its layout, update the script. Filling in a login form works only on simple sites: captchas and two-factor authentication cannot be bypassed.
Preview and testing
In the editor and in browser previews, the URL is shown in a regular iFrame, because only the device players provide the separate webview. A website that refuses embedding can therefore look blank in the preview while displaying correctly on the device. Check the result on a supported device.
Which URLs are accepted
This applies to the Windows player. The same restriction is being introduced on Android and is not yet released there.
A separate webview accepts a full HTTP or HTTPS web address. Other kinds of address — a local file path, or a data:, blob:, javascript: or similar address — are rejected, and no webview is created at all. On screen this looks like nothing happening rather than an error, so if a separate webview stays empty, check the address first.
A page that is already open may navigate to a blank page, which stays blank rather than reloading whatever was shown before.
If you use the optional script described above, note that it runs only on a real website response. It still runs on an ordinary error page returned by the site itself, such as a 404 or 500, but it does not run on a blank page or on the browser's own connection-failure page.
These restrictions limit which addresses a separate webview may open. They are not a sandbox, and they should not be relied on as isolation between the website and the player.
How the webview behaves on the device
The separate webview is a native element placed over the page, not part of the page itself. On Windows, it is always displayed above the rest of the content, so other widgets cannot appear on top of it. Touches on the website still count as user activity for the content.
When a page that uses a separate webview is hidden and shown again, the webview is concealed and revealed rather than destroyed and rebuilt, so the site keeps its page state instead of reloading. A page that required a login, a cookie acceptance or several steps of navigation is still where you left it when the content returns.
If a single device shows more than one native element at once — several separate webviews, or a separate webview alongside a video or stream player — they are stacked in a defined order rather than arbitrarily. This ordering applies between those native elements only; ordinary widgets are drawn by the page underneath them, which is why a separate webview still covers them on Windows.
Each separate webview runs as its own browser instance, which adds to the device's memory use. Lower-powered devices may not display it smoothly, so test on the hardware you plan to use.