Contact usRequest a demo

Limitations of embedded co-browsing

Embedded co-browsing relies on reading the DOM structure of a page on the visitor’s browser and re-assembling it in the agent’s browser. Because of the way browsers work, there are aspects of a page that may be difficult or impossible to reproduce using this technique.

What follows is an overview of the limitations you may encounter when using embedded co-browsing on an Unblu-enabled website. If you want to use embedded co-browsing on your website, you should take these limitations into account when designing or adapting the site.

Scalable Vector Graphics (SVG)


Works with embedded co-browsing with some limitations.

SVG animation

Animations on the visitor and agent side are out of sync.



Works with embedded co-browsing with some limitations.

New <input> types (date, color, range, number)

| Input fields are rendered by the browser, so the look and feel may differ if the visitor and agent are using different browsers.

autofocus attribute

Not supported

The autofocus attribute is ignored in embedded co-browsing sessions. The agent’s view doesn’t automatically focus on the input fields of the visitor’s shared content.



There are also some limitations with tainted canvases. Further details are available here.

Can be disabled for security reasons.

<video>, <audio>

Not supported

If used, the contents aren’t displayed on the agent side.

Web components


Works with some limitations.

Custom Elements specification


Shadow DOM specification


Attach shadow root elements with mode: 'open' so Unblu can mirror them for agents.

HTML Template specification


ES Module specification


HTML framesets

Not supported




  • If Unblu is only integrated in an iframe and not the topmost context of a page, you must set the variable x-unblu-root on the window instance. This is necessary to let the Unblu integration on the iframe know it can start embedded co-browsing itself. If x-unblu-root isn’t set, the agent only sees a gray frame in embedded co-browsing sessions.

  • If Unblu is integrated in an iframe, and the iframe is integrated in a container that’s smaller than the iframe itself, this may have a detrimental impact on how the iframe is displayed to the agent during embedded co-browsing. This is because Unblu has no way of determining the dimensions of the outer container.

    To work around this, you must integrate Unblu into both the iframe and the page the iframe is embedded in. Alternatively, ensure the size of the iframe and the container that it’s located in match.

See below for information on cross-origin iframes.



Works with some limitations.

font-size property

If undefined, or defined in em units, the font size is determined by the user’s browser. This information can’t be transferred to the agent, so their view won’t necesssarily be the same as the visitor’s.

CSS selectors level 3


Some selectors are supported in embedded co-browsing, some are known not to work.

Unsupported CSS selectors level 3

  • target

    Works syntactically but has not been tested in embedded co-browsing sessions.

  • enabled and disabled user interface elements

    Works syntactically but usually all user interface elements in Unblu are disabled—​if styled differently, the agent has a different view from the visitor.

CSS selectors level 4

Not supported

The current status with W3C is "working draft"; there is no official specification as yet.

CSS pseudo-classes

Elements shown when the visitor hovers over an element aren’t displayed on the agent side.

Browser-specific properties such as -moz-gradient

Not supported in on-premises setups with the resource history turned on.

CSS function style property values

CSS functions listed in com.unblu.server.css.safeFunctions are considered safe and are passed on one-to-one from visitor to agent, passing the Unblu CSS parser without further tests.

Note that this is only safe if the function in question has no parameters referencing external resources.

You should only change the default list after careful consideration.

The following functions are supported:

CSS3 animations

Animations aren’t in sync between the visitor and agent.

CSS Custom Properties

Not supported

The current status with W3C is "Candidate Recommendation"

Cross-Origin (x-origin)


Works with some limitations.

x-origin iframes


Include the Unblu snippet in all iframe pages.

Cross-origin Resource Sharing (CORS)


Changing protocol, origin, or port in an ongoing co-browsing session


This works, with some limitations, when only subdomains are changed.



Works with some limitations.

JavaScript navigation

Page elements displayed using onmouseover can’t be triggered on the agent side.

JavaScript alert(), confirm(), prompt()

Not supported

All operations that stop JavaScript entirely lead to problems with Unblu.

CSSRules created using CSSStyleSheet.insertRule()

Not supported

Styles created this way aren’t visible on the agent side.

Single page applications (SPA)



Depending on the CAPTCHA technology employed, the agent may see a different CAPTCHA from the visitor.


Not supported

Adobe Flash

Not supported

Banners or videos may work, but the visitor’s and agent’s view is out of sync.

Microsoft Silverlight

Not supported

Banners or videos may work, but the visitor’s and agent’s view is out of sync.

Java Applets

Not supported

The content isn’t transmitted to the agent.

ActiveX Objects

Not supported

Disabled for security reasons.

Limitations of virtualized environments

Unblu is Citrix ready and is compatible with Citrix’s Virtual Apps and Desktops service, Virtual Desktops, Workspace app, and Virtual Apps. However, virtualized environments like Citrix can have latency problems with Rich Internet Applications. If you’re using a virtualized environment and are having problems with "double-hop latency" you can install a browser locally.

For more information, refer to Browser requirements and the Citrix article on Local App Access.

Agent-side limitations

The limitations outlined below arise when an agent is controlling the page they’re co-browsing with a visitor. If you find you’re unable to eliminate these issues, you may prefer to use universal co-browsing instead.

The agent can’t trigger onChange() form actions

Some forms use dynamic actions that modify parts of the form when users make specific inputs. For example, a form may change the address fields depending on the country the user selects.

These actions are triggered only when the visitor makes a manual input, and not when Unblu fills the visitor’s form with input from the agent. Thus, when an agent changes a form field such as the customer’s home country, the form isn’t updated to display different fields.

You can work around this issue by, for example, adding JavaScript functionality to your page that checks the content of the relevant form fields once or twice per second instead of relying on the JavaScript onChange() event. Both mark mode and remote control are available in embedded co-browsing sessions. There are, however, some limitations, especially in remote control mode, that you should be aware of.

Mark mode

  • If the visitor scrolls the page while an agent is marking something, the marker will stay at the same absolute position. It won’t scroll with the rest of the page.

  • If the visitor and the agent are using different browsers, there can be a slight offset in the marked area on the agent and visitor side. This is due to differences in the way browsers render text.

The agent doesn’t trigger JavaScript events

Most interactions between a user and the page occur via built-in browser features, such as clicking a link or a button. However, it’s also possible that a page uses JavaScript to track what the user does and then reacts accordingly.

In such cases, the agent is unable to trigger some actions on the page because the page reacts only to the visitor's behavior but not the agent’s.

To check for this behavior on your website, switch off JavaScript and see if you can operate the website. Any behavior that stops working is due to the page using JavaScript.

There are three experimental configuration properties that fire events in certain circumstances and may let you work around these issues:

Limitations rendering <SELECT> elements

The <SELECT> element, or dropdown menu, doesn’t show up on the agent side when the visitor opens it. This is because the <SELECT> element is rendered natively by the operating system.

The list that appears by clicking the element isn’t represented in the DOM tree, so it isn’t recognized by Unblu. Once the visitor selects an option, their choice is visible to the agent.

Custom styling on <SELECT> elements also doesn’t appear on the agent side.

Limitations in cross-domain embedded co-browsing

Suppose your organization runs a corporate website,, that hosts general information about its products. It also runs separate customer websites for each country it operates in:,, and so on.

When a visitor to your Swedish website ( launches an embedded co-browsing session with an agent, you want them to be able to view the general information on the corporate website together, too. You want the embedded co-browsing session to allow switching between and and back.

Cross-domain embedded co-browsing has a number of requirements:

  • Unblu must be running in a cross-origin setup.

  • Your setup must support CORS.

  • All the instrumented websites must use the same Unblu account, the same API key, and the same Unblu server or cluster.

  • You must register all the domains you want to use in cross-domain embedded co-browsing sessions in the Unblu account.

  • Visitors must allow third-party cookies. The cookies used for the embedded co-browsing session are stored on the domain specified in com.unblu.identifier.publicServerBaseUrl.

DOM capturing performance issues

To create a visual representation of the client’s browser, the JavaScript must process all nodes of a page’s Document Object Model (DOM) and send them to the agent’s browser. Unblu DOM capturing is based on a JavaScript library.

Performance issues during DOM capturing can manifest in different ways:

  • The browser displays a warning to the client that a long-running JavaScript script has been detected.

  • The user can’t scroll or interact with the website until the JavaScript run is finished.

  • The browser can’t communicate with the Unblu server until the JavaScript run is finished.

The first two problems create a sub-par user experience but the third problem is critical. After a timeout is reached, the Unblu server assumes that the browser has stalled, but it can’t know the 'reason' for the problem.

Performance factors

The JavaScript must be able to capture the page’s DOM within a reasonable time. Three factors affect its ability to do so:

  1. Browser performance (executing the JavaScript)

  2. The power of the underlying hardware

  3. The complexity of the page’s DOM

The first two factors are beyond your control, but you can often affect the third one.

DOM complexity

The Unblu server has a feature that detects whether the page complexity (number of DOM nodes) exceeds a (configurable) limit. The limit is defined in the configuration property com.unblu.recorder.maxNodes, and its default value is 45000. If the complexity of the DOM tree exceeds this limit, the server aborts processing and displays the error message "Page too complex."

Unfortunately, simply increasing the limit doesn’t necessarily solve the problem. The complexity of a page’s DOM is influenced by other factors, too, so Unblu may display the error message "Page too complex" even if the number of nodes is smaller than the limit.

Addressing performance issues

One way to mitigate performance issues arising from the complexity of your pages' DOM is to encourage visitors to use a recent version of a modern browser such as Google Chrome, Microsoft Edge, or Mozilla Firefox.

The only way to eliminate the issues, however, is by taking this factor into account when designing the pages you want to be available in embedded co-browsing sessions.