mengw15 commented on code in PR #8600:
URL: https://github.com/apache/texera/pull/8600#discussion_r4051306793
##########
frontend/src/app/workspace/component/workspace.component.ts:
##########
@@ -173,13 +173,27 @@ export class WorkspaceComponent implements AfterViewInit,
OnInit, OnDestroy {
this.codeEditorService.vc = this.codeEditorViewRef;
}
+ /**
+ * The browser is leaving this document: save the workflow, and change
nothing else.
+ *
+ * Tearing the session down here was the cause of a page that came back
dead. A full-page
+ * navigation away (the Form View switch is one) fires this, and the browser
may then keep the
+ * document in its back/forward cache rather than discarding it. Coming back
restores the
+ * JavaScript state exactly as it was left, so whatever this method had
already destroyed stayed
+ * destroyed: an empty graph on a canvas that answered no clicks, and a
workflow id reset to the
+ * default, which the share dialog then asked the backend about and got an
error for. Nothing
+ * re-runs on a restore, because the component was never re-created.
+ *
+ * There is nothing to tear down on the way out anyway. A document that is
really discarded takes
+ * its websockets and its graph with it, and a document that comes back
needs them.
+ */
@HostListener("window:beforeunload")
- ngOnDestroy() {
- if (this.userService.isLogin() &&
this.workflowPersistService.isWorkflowPersistEnabled()) {
- const workflow = this.workflowActionService.getWorkflow();
-
this.workflowPersistService.persistWorkflow(workflow).pipe(untilDestroyed(this)).subscribe();
- }
+ onBeforeUnload(): void {
Review Comment:
There is a second way to the same symptom that this does not close, and it
is the gesture #8599 reports (the in-page switch, not Back). `ngAfterViewInit`
calls `resetAsNewWorkflow()`, which puts the metadata at `DEFAULT_WORKFLOW`
(wid 0) on every canvas load, and the real wid only arrives with the workflow.
The Share button carries no gate (`menu.component.html`, no `disabled`/`*ngIf`)
and the loading spinner sits in its own container, so a dialog opened in that
window asks `GET /workflow/type/0` and loses the Private/Public choice for good
— now with a toast rather than silently, which is an improvement but not the
same as having the buttons. That window is exactly where a user lands right
after the full-page switch, which may also be why the in-page path did not
reproduce: it needs the click to come before the workflow does. Worth either
gating the dialog on a loaded workflow or leaving #8599 open for it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
