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

Abierto
  • ¿Algo no está bien?
#1,594 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, typescript
Área
backend, devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
TypeScript
Estrellas
41
Forks
6
Merge medio
3 h 46 min
PR fusionados (30 d)
86

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sasjs/cli

Todos los issues de sasjs/cli

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.