Webpages and Embedded HTML on a Display

“It works in the preview but the screen is blank” is the defining symptom of webpage and embedded-HTML widgets, and it is not a bug. The preview runs in your browser, logged in as you, on your office network. The player runs a different browser engine, logged in as nobody, possibly on a different network. Anything that depends on those differences breaks.

Why the preview lies

Four things differ between your preview and the player:

Your session. If the page needs a login, your browser has the cookie and the player does not. The player gets a login screen, or, more often, a blank page.
Framing permissions. Most modern sites send headers that forbid being embedded in another page. Your preview may be exempt; the player is not. The page silently refuses to render.
Mixed content. An http:// page or asset embedded inside an https:// context is blocked outright.
The rendering engine. Player browser engines are older and stricter than desktop Chrome, especially on smart TVs and cheap Android boxes.

Fixes, in order of how often they work

1. Test the URL on the device itself

Open the device’s own browser and load the exact URL. If it fails there, no easyCMS setting will save it, you have a network, certificate or authentication problem to solve first. This single test resolves most cases.

2. Use the right render mode

The webpage widget offers different ways of rendering:

Open natively: the player loads the URL directly in its own browser. This bypasses framing restrictions and is the right choice for sites that refuse to be embedded. It cannot be layered under other content, and it takes the whole region.
Manual / embedded: the page is placed inside the layout. More flexible, but subject to every framing rule above.

If a page is blank in embedded mode, switch to open-natively and re-publish. That is the fix for the majority of blank webpage widgets.

3. Serve everything over HTTPS with a valid certificate

Self-signed and expired certificates are rejected without a visible error, and smart-TV players are the strictest of all. Use a certificate from a normal public authority. If you must use an internal certificate, it has to be installed as trusted on the device itself.

Signage cannot type a password. If the page needs authentication, expose a read-only version, a shared dashboard link, a public token URL, a published view, and point the widget at that instead.

5. Check what the page needs to run

Heavy JavaScript frameworks, WebGL, autoplaying media and web fonts loaded from third parties all fail more often on player hardware than on your laptop. The more static the page, the more reliable it is on a screen. Where you control the page, build a stripped-down signage version of it.

Dashboards specifically

Dashboards from analytics and BI tools are the most common webpage-widget use, and the most common failure. Almost all of them block embedding by default and require a session. Look for the tool’s own public link, published to web or read-only sharing feature, that produces a URL designed to be embedded, and it will work where the normal dashboard URL will not.

Embedded HTML

The embedded-HTML widget injects your markup into the layout. Common causes of a blank result:

Scripts loaded over http://, or from a domain the device cannot reach.
Code that assumes a desktop viewport size.
Markup that breaks the layout parse, an unclosed tag can invalidate the whole layout, which then never plays at all. See Scheduled Content Is Not Playing.

Test with a trivial block first, a coloured div with some text, to prove the widget itself works, then add your real code back a piece at a time.