I'm hitting a bug in V3 (all betas) where nodes get moved to the current tab on initial load. It's a race condition and doesn't always happen and I don't know yet how to create a repro. Here's a screen shot of how it looks, all the nodes that sit on top of others are really supposed to be in other tabs.
I've been debugging this and this is what I've found:
the flow file is correct and many times that I reload the browser everything shows correctly, but about 1 in 3 browser reloads results in the mess above
this happens because workspace_map[node.z] doesn't exist
the reason this doesn't exist is that importNodes gets called from the registery:node-type-added event handler with a list of nodes to reimport: node-red/nodes.js at master · node-red/node-red · GitHub and the list of nodes passed into importNodes only includes the nodes of that type and not any workspace nodes
in importNodes the workspace_map only includes workspace nodes that are passed in its argument list, not ones that have been previously imported, e.g. workspace_map is incomplete at the re-import time which the module global workspaces has all the workspaces.
This race condition is pretty fatal in that if one doesn't see the problem and deploys then the wrong placement of the nodes is saved.
It's a flexdash-related node. The bug happens when nodes of a given type are reimported when the type gets defined, that's why all the affected nodes are of the same type.
Can you explain that a bit more? The editor loads all of the node definitions before it loads the flow configuration from the runtime. So everything should already be defined and no nodes should be added to the editor "when the type gets defined".
Maybe I'm misunderstanding your meaning here, or there's some specific behaviour of your flexdash nodes that I'm missing?
Repro coming. Has nothing to do with FlexDash. If you follow the links to the code in my explanation above you can see how the node-type-added event handle re-imports nodes when the type gets defined.
That whole code path is related to when the flows are loaded with 'unknown' nodes - but the node type is subsequently added to the runtime. The editor can then update all of the 'unknown' nodes with the real nodes.
That is not a normal code path for when you open the editor. All of the types should be registered and available before the editor loads the flow configuration.
So I'll be interested to see your steps for reproducing this.
This issue is due to the fact, that - when opening the editor dialogs - the keyboard shortcut mapping is not disabled. I'll raise a PR to get this fixed.
Is there a constrain with V3 to use an older version of the dashboard? I am at V2.22 and cannot update because I am using an old iPad as main output screen.
Re: junction nodes. When I'm wiring to/from a junction node I'm finding it quite annoying that the node only expands when the cursor is on the junction dot and not already when it is on the yet-to-appear wiring dot. E.g., I know where the wiring dot will appear and I'd like to move the cursor right there, have it appear, and release the button. As opposed to having to move onto the main junction dot, wait for it to expand and show the two wiring dots, then slightly correct my mouse position so it's on the wiring dot, and then release the button.
Re: text editor. When I re-open a function node the editor remembers the previous text selection. That's probably good, dunno.. However, when I click somewhere else, it's as if I had shift-clicked, i.e. the selection gets extended to where I click. This happens systematically for me when I re-open a function node where I've previously set the cursor, not the first time I open one. Using Vivaldi (latest) or firefox (latest) on Linux.
In short, if you get helpful snippets, syntax errors for undefined variable, a command palette (f1 or right click), function intellisence, parameter help, jsdoc support and can see a mini map on the right - you have Monaco
If you get basic error highlighting (a red Mark in the left-hand column) you have ace (which will probably be dropped in the next version of node-red since Monaco provides a much richer experience)
