Labels
No labels
bug
docs
feature
housekeeping
html-spec
performance
react-compat
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
glow-all/true-headless-browser#94
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problembeschreibung (DE)
Zwei fundamentale Architektur-Probleme:
1. Module-Level Shared State in DynamicScriptHandler
In
src/js/dynamic-scripts.ts(Zeile 61) existiert module-level Shared State:Konsequenz: Test A erstellt Page -> laedt Scripts ->
processingElementshat Eintraege. Test B erstellt neue Page -> DIESELBEprocessingElementsMap wird weitergenutzt -> Scripts werden faeelschlicherweise als "bereits verarbeitet" erkannt -> 6 Test-Failures.2. Kein Unified Network Stack per Page
Aktuell verteilen sich Requests auf verschiedene, unabhaengige Komponenten:
Echter Browser: EIN Network-Stack pro Page/Ursprung. ALLES geht durch:
Analyse
Problem 1 Fix: Per-Instance processingElements
Problem 2: PageNetworkManager Architektur
Integration mit Page:
Optionen
Option A — Minimal: Nur Shared-State fixen (EMPFEHLUNG fuer sofort)
processingElementsvon Module-Level zu Instance-Level verschiebenOption B — Full PageNetworkManager (EMPFEHLUNG)
Option C — Hybrid: Minimal fix + NetworkManager Grundstruktur
Entscheidung
Option C — Shared-State fixen (Red Alert, blockiert Tests) + NetworkManager in Phasen. Phase 1 ist der Shared-State Fix. Phase 2+ folgen iterativ.
Akzeptanzkriterien
processingElementsist per DynamicScriptHandler-Instance, nicht module-levelloadedUrlsist bereits per-instance (bleibt unveraendert)PageNetworkManagerKlasse existiert mitrequest()Methodefetch()geht durch PageNetworkManagerXMLHttpRequestgeht durch PageNetworkManagerBetroffene Dateien
src/js/dynamic-scripts.tsprocessingElements-> instance-level (Zeile 61)src/network/network-manager.tssrc/network/cookie-jar.tssrc/pages/page.tsnetworkProperty hinzufuegensrc/runtime-isolation.tsfetch/XHRdurch NetworkManager ersetzensrc/js/script-loader.tsload()durch NetworkManager.request()src/execution-realm.tsInstrumentedFetchentfernen (durch NetworkManager)tests/unit/network-manager.test.tsTechnische Risiken
execution-realm.tshat eigene fetch/XHR-Proxy. Umstellung auf NetworkManager kann Race-Conditions ausloesen.Dependencies
Testplan
Gelöst in Commit
f6a8c4b✅Was wurde gemacht
Phase 1 — Shared-State Fix (processingElements):
processingElementsvon module-level (const) zu instance-level (private processingElements) inDynamicScriptHandler_queueDynamicund chunk-processing aktualisiertPhase 2 — PageNetworkManager (new):
src/network/network-manager.ts: Unified Network Pipeline pro PagesetTransport()zur Injektion der Transport-Funktion (via createFetch)fetch(),addInterceptor(),waitForRequest/Response,filterByUrl/Transport/StatusTests
Nächste Schritte (separates Issue)