Bug 2026039391: Fehler unendlicher Loading-Screen bei Restart der Application

[NVNKL]

Infos

• HtmlClient wird erst neu gebaut, wenn FrameworkSystemsGmbH/fs#1780 gemerged wurde.
• Version Bump wurde dort auch bereits gemacht.

Problem

Die login()-Methode im broker.service.ts hat kein fireLoadingChanged(false) nach der Verarbeitung der Response. Beim Erstlogin fällt das nicht auf, weil die ViewerComponent zu dem Zeitpunkt noch nicht existiert (User ist auf der Login-Seite). Der _onLoadingChanged$$ ist ein Subject, kein BehaviorSubject — die ViewerComponent bekommt also nur Emissionen, die nach seiner Subscription kommen.

Beim Restart ist die ViewerComponent aber bereits aktiv und subscribed:

fireLoadingChanged(false) → isLoading = false
doRequest() → fireLoadingChanged(true) → isLoading = true
Kein fireLoadingChanged(false) kommt → isLoading bleibt permanent true

Warum keine Umstellung auf BehaviorSubject?

Subject: Neue Subscriber bekommen nur zukünftige Emissionen.
BehaviorSubject: Neue Subscriber bekommen sofort den letzten Wert bei Subscription.

Konkrete Auswirkung

Der ViewerComponent subscribed sich in ngOnInit auf onLoadingChangedDelayed:

Erstlogin: login() → doRequest() → fireLoadingChanged(true) → Response verarbeitet → onAfterResponse() → showViewer() → ViewerComponent wird erstellt und subscribed.

Mit Subject: ViewerComponent bekommt nichts → isLoading bleibt false → kein Blocker
Mit BehaviorSubject: ViewerComponent bekommt sofort true → Blocker wird angezeigt, obwohl das Loading eigentlich schon vorbei ist

Das ist genau der Grund, warum es aktuell beim Erstlogin funktioniert — der Subject "vergisst" das true, das vor der Subscription emittiert wurde. Mit einem BehaviorSubject würdest du das bestehende (funktionierende) Erstlogin-Verhalten kaputt machen.

Der Subject ist hier also die richtige Wahl. Das eigentliche Problem war nicht der Subject-Typ, sondern das fehlende fireLoadingChanged(false) in der login()-Pipeline — und das ist jetzt mit dem finalize behoben