OMID browserOptional describes the JavaScript environment.

The name browserOptional is easy to misread as permission to skip verification JavaScript. It describes the script's execution environment. Confusing those meanings can leave a player showing video while the required verification resource never runs.

This is especially relevant when a player moves from a browser test page to an app or another environment with a different JavaScript runtime. The same resource URL does not establish the same available APIs.

VAST 4.3 section 3.17.1 provides the selection rules. The integration work is to apply them to a real environment, preserve the selected resource and verify what actually executed.

Describe the environment precisely

A resource marked browserOptional="true" declares support for execution without DOM and other browser built-ins. The resource remains JavaScript. The flag does not replace it with a native measurement vendor SDK.

For browser or webview execution, the specification prefers resources marked false when both forms are available. A non-browser JavaScript environment may execute only resources marked true. If it receives only unsuitable resources, the associated not-executed reporting must remain visible.

Start an integration record with the player build, OM SDK integration, runtime and supported framework. Avoid a single isNative variable that attempts to represent all those properties. An app can host a webview, and a platform label alone does not tell you which environment executes verification code.

Validate the XML attribute before selecting a resource

An XML parser usually returns attribute text. In JavaScript, Boolean("false") evaluates to true. The string is nonempty, so ordinary truthiness does not interpret its XML meaning.

The following complete Node.js example accepts XML Schema boolean forms and then applies a narrow resource-selection rule:

import assert from 'node:assert/strict'; function parseXmlBoolean(value) { if (typeof value !== 'string') { throw new TypeError('browserOptional attribute is missing'); } const lexical = value.trim(); if (lexical === 'true' || lexical === '1') return true; if (lexical === 'false' || lexical === '0') return false; throw new TypeError('invalid XML boolean'); } function selectForEnvironment(resources, environment) { if (resources.some(r => typeof r.browserOptional !== 'boolean')) { throw new TypeError('resources must contain validated booleans'); } if (environment === 'browser') { return resources.find(r => r.browserOptional === false) ?? resources[0] ?? null; } if (environment === 'non-browser-js') { return resources.find(r => r.browserOptional === true) ?? null; } throw new Error('unknown execution environment'); } const resources = [ { id: 'portable', browserOptional: parseXmlBoolean('true') }, { id: 'browser', browserOptional: parseXmlBoolean('false') } ]; assert.equal(selectForEnvironment(resources, 'browser').id, 'browser'); assert.equal(selectForEnvironment(resources, 'non-browser-js').id, 'portable'); assert.equal(selectForEnvironment([resources[1]], 'non-browser-js'), null); assert.equal(parseXmlBoolean('0'), false); assert.equal(parseXmlBoolean(' 1 '), true); assert.throws(() => parseXmlBoolean(undefined)); assert.throws(() => parseXmlBoolean('False')); assert.throws(() => selectForEnvironment([{ browserOptional: 'false' }], 'browser'));

The selector deliberately assumes that the caller already filtered resources for the relevant verification entry and supported API framework. It illustrates environment selection, not the complete VAST verification algorithm.

The parser preserves missing or invalid values as errors. Supplying a default at this stage would hide a malformed declaration and make the later selection look justified.

Keep eligibility separate from successful execution

Selecting the portable resource establishes that it is eligible under this environment rule. Several later questions remain: did the player fetch it, did loading complete, did its execution succeed and did it participate in the expected measurement session?

Record these as separate outcomes. A resource that was eligible but failed to load needs a different investigation from a resource the player never selected.

Keep the verification vendor, selected URL, resource position in the document and environment in the diagnostic record. If wrappers add verification entries, preserve which document introduced each one. Otherwise a report can identify the wrong vendor script when several resources are present.

Do not conclude that measurement worked merely because a global JavaScript object exists. Check the integration's documented session and event observations. The exact instrumentation depends on the SDK and platform, so retain the build and test environment with that evidence.

Test the matrix that your deployment will use

Create one fixture with a browser-only resource, one with a portable resource and one containing both. Run them against each execution environment your product supports.

For the browser environment, verify the selection preference when both forms are offered. For the non-browser environment, verify that the browser-only fixture cannot accidentally pass because a desktop test harness supplies a DOM.

Add a fixture with a missing attribute and another containing the text false. The latter specifically guards against a future refactor replacing deliberate parsing with Boolean(value).

Keep environment selection deterministic. If two resources are equally eligible, document the implementation's selection behavior rather than allowing iteration order from an unrelated data structure to choose the script accidentally.

Use runtime failures to narrow the next step

If a resource is never selected, inspect the parsed declaration and framework filtering first. If it is selected but never requested, inspect the player's execution policy and instrumentation. If the request occurs but execution fails, inspect the response, loading restrictions and runtime diagnostics.

A script can also depend on browser APIs despite declaring portability. Retain a minimal reproduction in the actual non-browser runtime, with the vendor resource revision. Changing the flag in your local XML without checking the script's behavior does not repair that dependency.

When no verification executes, preserve the associated failure reporting. Missing measurement is an operational result that needs explanation, not a successful session with zero measured activity.

Put the declaration and observation in the same review

A useful acceptance record includes the XML fixture, parsed boolean, selected resource, runtime identity and measurement-session observation. Another engineer should be able to determine where the check stopped without rerunning the entire campaign.

I maintain VASTlint. Use the VAST XML validator to inspect the declaration before the environment test. Keep its structural result beside the player evidence, so each result supports the question it actually checked.