Good Practices


Exception handling should be used with try/catch. Unhandled exceptions could disable the HTML5 player in some of its functions. If errors occur that could harm the normal execution of the player, Admira will not be responsible for the consequences.


The execution of content or WebApps occurs within a sandboxed HTML <iframe> TAG. This iframe sandbox contains the following permissions enabled:

  • allow-forms Re-enables form submission

  • allow-pointer-lock Re-enables APIs

  • allow-same-origin Allows the iframe content to be treated as being from the same origin

  • allow-scripts Re-enables scripts

By cons are not allowed:

  • top-navigation; (esto es, solo se puede usar “_self” en target de links)

  • popups

Access to external resources

Each case is different. In the case of wanting to access resources from other “sites”, the execution policies from an <iframe> must be taken into account. This means that options like X-Frame-Options or CORS must be set correctly on the server we want to make the request to. In short, the WebApps that we want to run in admire <iframe> do not run as in a browser, but in an “unattended window”.

ASYNC requests

It is important to note that any request made either abroad (url on the internet) or locally (file on filesystem) must be done ASYNCHRONOUSLY, since the HTML content shares an execution THREAD with the player. Therefore, if a SYNC request were to occur, the player would stop until the request was finished. This can cause serious problems running player. Therefore, ALL requests must be made ASYNCHRONO, just as any execution of SYNCRONO blocking code must be avoided so that it does not cause an unusual stop to the player.

On this website we can simulate blocking of requests:

Where 3000 is the delay in milliseconds.

Last updated