Gefunden beim CI-Fehler zu 592ea94 (#186, Task 217).
Symptom: Wählt man für eine Form Fill type → Texture und ein Bild, bleibt die Form im Vector-Art-Tab in ihrer Grundfarbe. Erst der nächste Redraw (irgendeine Änderung, Auswahl, Größenänderung) zeigt die Textur.
Gemessen (Vollauf aller e2e-Module, lokal):
Nach der Auswahl 3 s lang alle 100 ms den Tab-Pixel gelesen: bleibt blau (#0000ff, Grundfarbe).
Danach __gm.state.preview(): sofort richtig (#e63c3c / #3cc85a).
Keine Exception im Browser.
Nicht reproduzierbar mit Modul 47 allein oder mit 28 + 47. Tritt also nur nach Vorarbeit anderer Module auf.
Code-Pfad:VectorArtCanvas meldet sich per textureLibrary.onChange(() => this.redraw()) an, fillOf in vectorArtPicture.ts liefert null, solange textureLibrary.get(ref, 'repeat') nichts hat. Offenbar kommt im langen Lauf kein onChange nach dem Laden an, oder das Laden läuft über einen Weg, der keins auslöst (z. B. Datei schon in loading/failed von einem früheren Modul, oder Pixi-Assets-Cache).
Stand im Test: Block 47i stößt nach kurzem Warten den Redraw selbst an und prüft danach die Pixel. Mit diesem Issue fliegt das wieder raus.
Gefunden beim CI-Fehler zu `592ea94` (#186, Task 217).
**Symptom:** Wählt man für eine Form *Fill type → Texture* und ein Bild, bleibt die Form im Vector-Art-Tab in ihrer Grundfarbe. Erst der nächste Redraw (irgendeine Änderung, Auswahl, Größenänderung) zeigt die Textur.
**Gemessen (Vollauf aller e2e-Module, lokal):**
- Nach der Auswahl 3 s lang alle 100 ms den Tab-Pixel gelesen: bleibt blau (`#0000ff`, Grundfarbe).
- Danach `__gm.state.preview()`: sofort richtig (`#e63c3c` / `#3cc85a`).
- Keine Exception im Browser.
**Nicht reproduzierbar** mit Modul 47 allein oder mit 28 + 47. Tritt also nur nach Vorarbeit anderer Module auf.
**Code-Pfad:** `VectorArtCanvas` meldet sich per `textureLibrary.onChange(() => this.redraw())` an, `fillOf` in `vectorArtPicture.ts` liefert `null`, solange `textureLibrary.get(ref, 'repeat')` nichts hat. Offenbar kommt im langen Lauf kein `onChange` nach dem Laden an, oder das Laden läuft über einen Weg, der keins auslöst (z. B. Datei schon in `loading`/`failed` von einem früheren Modul, oder Pixi-`Assets`-Cache).
**Stand im Test:** Block 47i stößt nach kurzem Warten den Redraw selbst an und prüft danach die Pixel. Mit diesem Issue fliegt das wieder raus.
Die Texturfüllung selbst war nie das Problem. Ausgelöst hat den Fehler e2e-Modul 45 (abmelden, wieder anmelden):
Beim Abmelden zerstört Editor.dispose() den Arbeitsbereich. TextureCanvas, TileCanvas, ShaderPreview und WorldViewport hatten sich bei der textureLibrary angemeldet und nie wieder abgemeldet. Die Bibliothek ist ein Singleton und überlebt das Abmelden.
Nach dem neuen Anmelden reiht sich der Vector-Tab hinter diesen toten Listenern ein.
Ist eine Textur fertig geladen, ruft notifyChange() zuerst einen toten Canvas auf. Der wirft TypeError: Cannot read properties of null (reading 'clear'), und die Schleife bricht ab. Der Vector-Tab erfährt nie, dass das Bild da ist.
Oben steht, im Browser gäbe es keine Exception. Das war falsch, die Gegenprobe zeigt sie deutlich.
Fix
Die vier Widgets melden sich in destroy() ab. Das ist dasselbe Muster wie in FontPreview und VectorArtCanvas. WorldViewport meldet sich bei der Textur- und bei der Schrift-Bibliothek ab.
FileLibrary.notifyChange fängt Fehler je Listener ab. Ein kaputter Listener hält die anderen nicht mehr auf. Der Fehler bleibt als [textures] a listener failed in der Konsole sichtbar.
Block 47i erzwingt keinen Redraw mehr. Der Check wartet höchstens 3 s darauf, dass der Tab die Textur von selbst zeigt.
2 neue Unit-Tests in tests/viewport/file-library.test.ts: Ein werfender Listener hält den nächsten nicht auf, und ein abgemeldeter Listener wird nicht mehr aufgerufen.
Gegenprobe im Browser: Alter Quellcode und neuer Check ergeben mit GM_STEPS=45,47 genau 1 FAIL (die Form bleibt #0000ff) plus den TypeError.
Gegenprobe am Unit-Test: Mit dem alten FileLibrary.ts fällt der erste Test.
Die Zahl der e2e-Checks bleibt gleich. Einen lokalen Vollauf gab es nicht, das Ergebnis zeigt CI.
Behoben in 6a2b06d.
## Ursache
Die Texturfüllung selbst war nie das Problem. Ausgelöst hat den Fehler **e2e-Modul 45** (abmelden, wieder anmelden):
1. Beim Abmelden zerstört `Editor.dispose()` den Arbeitsbereich. `TextureCanvas`, `TileCanvas`, `ShaderPreview` und `WorldViewport` hatten sich bei der `textureLibrary` angemeldet und nie wieder abgemeldet. Die Bibliothek ist ein Singleton und überlebt das Abmelden.
2. Nach dem neuen Anmelden reiht sich der Vector-Tab **hinter** diesen toten Listenern ein.
3. Ist eine Textur fertig geladen, ruft `notifyChange()` zuerst einen toten Canvas auf. Der wirft `TypeError: Cannot read properties of null (reading 'clear')`, und die Schleife bricht ab. Der Vector-Tab erfährt nie, dass das Bild da ist.
Oben steht, im Browser gäbe es keine Exception. Das war falsch, die Gegenprobe zeigt sie deutlich.
## Fix
- Die vier Widgets melden sich in `destroy()` ab. Das ist dasselbe Muster wie in `FontPreview` und `VectorArtCanvas`. `WorldViewport` meldet sich bei der Textur- und bei der Schrift-Bibliothek ab.
- `FileLibrary.notifyChange` fängt Fehler je Listener ab. Ein kaputter Listener hält die anderen nicht mehr auf. Der Fehler bleibt als `[textures] a listener failed` in der Konsole sichtbar.
- Block 47i erzwingt keinen Redraw mehr. Der Check wartet höchstens 3 s darauf, dass der Tab die Textur von selbst zeigt.
## Tests
```
./check.sh → 137 Files, 2051 Tests, CHECK EXIT 0 (vorher 136 / 2049)
GM_STEPS=45,47 (frisch) → ALL PASSED – 71 checks, keine Exception
```
- 2 neue Unit-Tests in `tests/viewport/file-library.test.ts`: Ein werfender Listener hält den nächsten nicht auf, und ein abgemeldeter Listener wird nicht mehr aufgerufen.
- Gegenprobe im Browser: Alter Quellcode und neuer Check ergeben mit `GM_STEPS=45,47` genau 1 FAIL (die Form bleibt `#0000ff`) plus den TypeError.
- Gegenprobe am Unit-Test: Mit dem alten `FileLibrary.ts` fällt der erste Test.
- Die Zahl der e2e-Checks bleibt gleich. Einen lokalen Vollauf gab es nicht, das Ergebnis zeigt CI.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Gefunden beim CI-Fehler zu
592ea94(#186, Task 217).Symptom: Wählt man für eine Form Fill type → Texture und ein Bild, bleibt die Form im Vector-Art-Tab in ihrer Grundfarbe. Erst der nächste Redraw (irgendeine Änderung, Auswahl, Größenänderung) zeigt die Textur.
Gemessen (Vollauf aller e2e-Module, lokal):
#0000ff, Grundfarbe).__gm.state.preview(): sofort richtig (#e63c3c/#3cc85a).Nicht reproduzierbar mit Modul 47 allein oder mit 28 + 47. Tritt also nur nach Vorarbeit anderer Module auf.
Code-Pfad:
VectorArtCanvasmeldet sich pertextureLibrary.onChange(() => this.redraw())an,fillOfinvectorArtPicture.tsliefertnull, solangetextureLibrary.get(ref, 'repeat')nichts hat. Offenbar kommt im langen Lauf keinonChangenach dem Laden an, oder das Laden läuft über einen Weg, der keins auslöst (z. B. Datei schon inloading/failedvon einem früheren Modul, oder Pixi-Assets-Cache).Stand im Test: Block 47i stößt nach kurzem Warten den Redraw selbst an und prüft danach die Pixel. Mit diesem Issue fliegt das wieder raus.
Behoben in
6a2b06d.Ursache
Die Texturfüllung selbst war nie das Problem. Ausgelöst hat den Fehler e2e-Modul 45 (abmelden, wieder anmelden):
Editor.dispose()den Arbeitsbereich.TextureCanvas,TileCanvas,ShaderPreviewundWorldViewporthatten sich bei dertextureLibraryangemeldet und nie wieder abgemeldet. Die Bibliothek ist ein Singleton und überlebt das Abmelden.notifyChange()zuerst einen toten Canvas auf. Der wirftTypeError: Cannot read properties of null (reading 'clear'), und die Schleife bricht ab. Der Vector-Tab erfährt nie, dass das Bild da ist.Oben steht, im Browser gäbe es keine Exception. Das war falsch, die Gegenprobe zeigt sie deutlich.
Fix
destroy()ab. Das ist dasselbe Muster wie inFontPreviewundVectorArtCanvas.WorldViewportmeldet sich bei der Textur- und bei der Schrift-Bibliothek ab.FileLibrary.notifyChangefängt Fehler je Listener ab. Ein kaputter Listener hält die anderen nicht mehr auf. Der Fehler bleibt als[textures] a listener failedin der Konsole sichtbar.Tests
tests/viewport/file-library.test.ts: Ein werfender Listener hält den nächsten nicht auf, und ein abgemeldeter Listener wird nicht mehr aufgerufen.GM_STEPS=45,47genau 1 FAIL (die Form bleibt#0000ff) plus den TypeError.FileLibrary.tsfällt der erste Test.