Task Summary
WorkflowEditorComponent finds the element it builds its JointJS paper into with a document-wide lookup:
// 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
Task Summary
WorkflowEditorComponentfinds the element it builds its JointJS paper into with a document-wide lookup: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
ngAfterViewInitwhile 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:
after resolving the container from the component's own host:
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
mainas 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 fromdocument, with a test that a second instance created while a decoy#workflow-editorsits 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.updateNavigatorreads it to place the navigator rectangle (self-corrects on the next pointer event) andReportGenerationServicereads it to snapshot the canvas.Found while browser-testing #8581.
Task Type