You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@texera.apache.org by "yangzhang75 (via GitHub)" <gi...@apache.org> on 2026/09/19 03:03:15 UTC

[I] The workflow editor takes its container from the document, so a second instance leaves the canvas blank [texera]

yangzhang75 opened a new issue, #8606:
URL: https://github.com/apache/texera/issues/8606

   ### Task Summary
   
   `WorkflowEditorComponent` finds the element it builds its JointJS paper into with a document-wide lookup:
   
   ```ts
   // workflow-editor.component.ts, ngAfterViewInit
   this.editor = document.getElementById("workflow-editor")!;
   this.editorWrapper = document.getElementById("workflow-editor-wrapper")!;
   ...
   this.paper = this.wrapper.attachMainJointPaper({ el: this.editor, ... });
   ```
   
   The ids come from the component's own template (`<div id="workflow-editor-wrapper"><div id="workflow-editor">`), so every instance of this component renders elements carrying them. The lookup therefore does not return *this* instance's container; it returns whichever is first in document order.
   
   That is fine as long as only one instance is ever in the page, which is the case today. It stops being fine the moment two are, and two views already mount this same component: the operator canvas mounts it as the canvas, and the Form View mounts it as the read-only workflow preview.
   
   **Consequence.** With the canvas <-> Form View switch routed rather than reloaded (#8580), the two instances overlap for one tick: the arriving view runs `ngAfterViewInit` while the departing view's DOM is still attached. The arriving canvas then builds its paper into the *departing* view's container, which is removed moments later. The canvas is left with an empty `<div id="workflow-editor">`: no SVG, no cells, nothing to pan and nothing to click, while the graph itself is untouched -- the Form View's preview goes on showing it, including a run in progress, right up until the switch.
   
   Measured in a browser at the moment the canvas comes back, with the switch routed:
   
   ```
   [GETBYID] workflow-editor: 2 in document, returned index 0
             #workflow-editor  box=1399x1000  svg=false  cells=0
   ```
   
   after resolving the container from the component's own host:
   
   ```
             #workflow-editor  box=1399x1000  svg=true   cells=1
   ```
   
   No run is needed: expanding the Form View's preview once and switching back is enough. Watching a run in the preview simply makes it certain, because that is when a reader expands the preview.
   
   **Not reproducible on `main` as it stands.** The switch is still a full page load there, so the two instances never coexist and the lookup is always right. This is a latent defect that any in-process switch turns into a blank canvas, and it is wrong on its own terms regardless: a component should not reach outside itself for its own element, and two elements sharing an id in one document is invalid HTML.
   
   Proposed: resolve both elements from the component's own host (`ElementRef`, already injected) instead of from `document`, with a test that a second instance created while a decoy `#workflow-editor` sits earlier in the document still builds its paper in its own container.
   
   Two more document-wide lookups of the same id exist and are worth a look while this is open, though neither leaves a stuck state: `MiniMapComponent.updateNavigator` reads it to place the navigator rectangle (self-corrects on the next pointer event) and `ReportGenerationService` reads it to snapshot the canvas.
   
   Found while browser-testing #8581.
   
   ### Task Type
   
   - [x] Bug Fix
   


-- 
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: notifications-unsubscribe@texera.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] The workflow editor takes its container from the document, so a second instance leaves the canvas blank [texera]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on issue #8606:
URL: https://github.com/apache/texera/issues/8606#issuecomment-5738859838

   <!-- texera:template-compliance -->
   👋 Thanks for opening this issue, @yangzhang75!
   
   It looks like the issue description doesn't quite follow our template yet:
   
   - This issue doesn't appear to use one of our templates (Bug, Feature, or Task). Please open it using a template so the required details are captured.
   
   Filling out the template helps reviewers understand and triage your contribution faster. Please edit the description to complete it. This message will disappear automatically once the template is followed.
   
   You can find the template prompts by editing the description, or see [CONTRIBUTING.md](https://github.com/apache/texera/blob/main/CONTRIBUTING.md) for the full contribution flow.
   


-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] The workflow editor takes its container from the document, so a second instance leaves the canvas blank [texera]

Posted by "mengw15 (via GitHub)" <gi...@apache.org>.
mengw15 closed issue #8606: The workflow editor takes its container from the document, so a second instance leaves the canvas blank
URL: https://github.com/apache/texera/issues/8606


-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] The workflow editor takes its container from the document, so a second instance leaves the canvas blank [texera]

Posted by "yangzhang75 (via GitHub)" <gi...@apache.org>.
yangzhang75 commented on issue #8606:
URL: https://github.com/apache/texera/issues/8606#issuecomment-5782972957

   Scope note, since #8581 says it closes this. What lands there: the editor's own two lookups (`#workflow-editor`, `#workflow-editor-wrapper`) and the mini-map's three (`#mini-map`, `#mini-map-navigator`, and the main canvas's element for the navigator, now the main paper's own `el`), plus the property panel's `#right-container`, which the same audit found. `ReportGenerationService` and `dashboard.component.ts` still look `#workflow-editor` up in the document; both are single-instance today and off the switch's path, so they are left as they are. If either ever runs while a second editor is mounted, this is the issue to reopen.


-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org