FIX: Wait for the page to load before warning that no preference platform was found

[jwrosewell]

The problem

On a page that is correctly integrated, the client script logs this on a
first visit:

51Degrees: no preference platform was found on this page. A platform's stub
must precede this script. No 51Did will be created until a platform answers.

A preference management platform's bundle loads asynchronously, so
__tcfapi is not registered at the moment this script constructs. The
script then picks the answer up from the 51d-pmp-preference window event
and everything works, so the line is noise, and anyone with the console
open reads it as an integration error.

The two sides had different rules for the same question. A preference
management platform waits for the client script's object before deciding
the script is absent, and that wait ends at the page's load event or after
5000 milliseconds, whichever comes first, with no wait at all where the
page has already loaded. The client script decided at construction, which
is the one moment an asynchronous tag has reliably not run yet.

The change

JavaScriptResource.mustache, inside the user prompt block. The warning
now waits in the same shape:

• Nothing is printed while the page is still loading.
• The wait ends at the page's load event, or after 5000 milliseconds,
  whichever comes first, so a page whose load event is very late or never
  comes is still told.
• A page that has already loaded waits for nothing, because a platform
  that is not there then is not coming from a tag the markup carries.
• An answer from any source during the wait, or a platform that registers
  during it, means nothing is printed, because a 51Did will be created.
• Where no platform ever appears the warning is printed exactly as it was,
  with the same text, because that case matters and the line is the only
  signal the page gets.

The wait only logs. It changes nothing about processing, no request waits
for it, and no value is ever printed. The existing failure handling style
in the block is followed, so every read that a stub could make throw is
wrapped and nothing here can stop process().

Environments with no window, no addEventListener or no setTimeout,
which is where the cloud's server side evaluation runs this script, warn
at once as before rather than waiting for a page that does not exist.

Evidence

The template is shared by every language's builder, so the rendered output
had to stay the same in every other respect. Rendering the template before
and after with the same model and comparing:

• with the user prompt block off, the rendered script is byte for byte
  identical;
• with the block on, the only difference is this one function.

node tests/template-tests.js:

• before: 157 checks, 0 failures
• after: 176 checks, 0 failures

One existing check changed meaning, from "a page with no platform at
construction is warned once" to "a page still loading is not warned about
a missing platform", which is the behaviour under test here. Nineteen
checks were added in a new section, "The wait before the missing platform
warning", covering:

• nothing is said while the page is still loading, and the wait is held on
  the page's load event;
• a page that loads with no platform is warned once, with the same text it
  always got, and the load listener is removed afterwards;
• a second load event does not repeat it;
• the wait is bounded at 5000 milliseconds, a page whose load event never
  comes is warned at that limit, and a load event after the limit does not
  repeat it;
• an answer arriving during the wait stops the warning, and that answer
  still reaches the request;
• a platform that registers during the wait stops the warning;
• a page that has already loaded is warned at once and waits for nothing;
• a platform present at construction is neither waited for nor warned
  about;
• neither the warning nor the 5000 millisecond limit appears in a script
  rendered without the user prompt block.

The 5000 millisecond limit is reached in the tests through a setTimeout
the test drives, so the suite does not sit waiting five seconds for it.

Found while working on the 51Degrees website against cloud release
4.4.38.

Without the change

The counts above show the suite is green before and after, which on its own does not show the new checks would have caught the fault. Running this branch's tests/template-tests.js against the JavaScriptResource.mustache from main, with nothing else altered, gives:

  FAIL  a page still loading is not warned about a missing platform
  FAIL  nothing is said whilst the page is still loading
  FAIL  the wait is held on the page's load event
  FAIL  the wait is bounded at 5000 milliseconds
  FAIL  nothing is said before that limit is reached
  FAIL  an answer arriving during the wait stops the warning
  FAIL  a platform that registers during the wait stops the warning
176 checks, 7 failures

Six of the nineteen new checks fail there, together with the one existing check whose meaning changed. The other thirteen describe behaviour the block already had, such as the warning text itself and a platform found at construction being neither waited for nor warned about, so they pass either way and are there to hold that behaviour still.

Related, and what has to follow

This and #31, which stores a snippet's result only under a name the snippet writes, both change JavaScriptResource.mustache, in different parts of the file. Merging the two branches together locally in both orders needed no conflict resolution, and node tests/template-tests.js on the result reports 207 checks, 0 failures either way, so the merge order does not matter.

The Rust SDK keeps its own copy of the template at javascript-builder/assets/JavaScriptResource.mustache and checks it against this repository. Its pull request and push builds compare against a pinned commit, but the Monday 04:00 schedule and a manual run compare against main, so that weekly check goes red once this is merged and stays red until 51Degrees/rust#52 moves the bundled copy and the pinned reference together in one pull request. The .NET, Java, Node and Python pipelines take this repository as a submodule and the PHP pipeline reads JavaScriptResource.mustache from a javascript-templates directory beside its source, so each of them picks the change up only when it next moves that pointer and publishes a package.

Left for the reviewer to judge

Where the page has already loaded the warning is printed at once with no wait. A page that injects both this script and its preference management platform after the load event, which a tag manager can do, therefore still gets the line on a first visit even though the platform is on its way. The alternative is to wait 5000 milliseconds on every late injection, which delays the one signal a genuinely unintegrated page gets.

Merge order

The three ready pull requests in this repository take this order:

29, 32, 31

Merges before this one: 29.

This and 31 both change JavaScriptResource.mustache and tests/template-tests.js, in different parts of each file, and git merge-tree finds no conflict between them in either direction.

No branch had to be changed for this order. Every pair was measured with git merge-tree, the three were then merged into main in that order as real merges with no conflict, and npm test in tests on the result reports 207 checks, 0 failures. Smallest and most self-contained first. Checked on 17 September 2026.