Mock build: a page that initialises on window.onload renders nothing

Open
  • Is something wrong?
#1,594 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript, typescript
Domain
backend, devtools

Research direction

Start by reading host/boot.js, especially replayAll and the boot-anyway fallback, then trace when replayed scripts run relative to the page’s DOMContentLoaded and load events. Reproduce with the minimal seed app and a mock build. Done means pages that register load handlers during script replay initialize correctly, including in the fallback path, without breaking scripts replayed before the real load event.

Written by the indexing model from the issue text.

Description

Symptom

A page that initialises on window.onload renders nothing in a mock build: no error, no failed request, a blank app. The app's own scripts do run - they just run after the load event, so the handler they assign never fires.

First consumer to hit it: sasjs/minimal-seed-app (the template sasjs create --template minimal downloads), whose src/scripts.js ended with window.onload = function () { ... }.

Repro

npx @sasjs/[email protected] create demo --template minimal
cd demo
npx sasjs compile -t mock && npx sasjs build -t mock   # after adding a mock target
npx http-server sasjsbuild/mock -p 3001

Headless chromium against http://localhost:3001 (the page never leaves the login screen; the app's sasjs object is never constructed):

events: ["DOMContentLoaded 263", "load 270"]
readyState: "complete"
window.onload: "function"        <- assigned by the replayed script
typeof sasjs: "undefined"        <- startApp() never ran

Cause

host/boot.js replays the page's script tags once the worker claims the page - necessarily after load, since that needs registration + activation. Its own header says the tags run "just later than the parser would have run them"; for load listeners they run after it, and an assignment to window.onload at that point is never called.

Why it matters beyond this app

window.onload (and addEventListener('load')) is an ordinary way to initialise a page, especially a classic-script app with no bundler - which is exactly the app shape a minimal seed app is. The failure is silent: nothing in the console, nothing in the network tab, so it reads as "the mock build is broken" rather than "your init hook was missed". data-early does not help - a handler that needs the worker cannot run early.

Suggested fix

In boot.js, after replayAll completes (and in the boot-anyway fallback), if the document has already finished loading, dispatch the event(s) the replayed scripts expect:

function fireIfMissed() {
  if (document.readyState !== 'complete') return
  // DOMContentLoaded and load have both already fired by now
  document.dispatchEvent(new Event('DOMContentLoaded'))
  window.dispatchEvent(new Event('load'))
}

Dispatching a synthetic load is safe here because the real one has already happened - no handler gets it twice, and a script replayed before the real load (a fast worker) still receives the genuine event.

An alternative, if a synthetic event is judged too blunt: warn when a replayed script assigns window.onload, naming the script, so the failure is visible. I would rather it worked.

Not filing this as a PR because the app-side workaround is cheap and the shape of the fix is a design call for the host: sasjs/minimal-seed-app now starts on DOMContentLoaded/immediately, which works in both directions. Other apps will keep hitting it.

Version

@sasjs/cli 6.27.3, Chromium 153 (headless), Linux. Found while adding a mockWeb target to the minimal seed app: https://github.com/sasjs/minimal-seed-app/pull/29

Dominant language
TypeScript
Stars
41
Forks
6
Avg merge
3h 46m
Merged PRs (30d)
86

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sasjs/cli

All issues in sasjs/cli

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.