some time ago @Thierry has created a very useful pull request to add the persistantFrontEndValue property to the addWidget function.
That new property has helped me already a lot in some of my UI nodes to avoid that the last input message is automatically replayed again after a dashboard page refresh. For example in the node-red-contrib-ui-contextmenu node. Otherwise e.g. the last contextmenu would popup automatically after a page refresh, but currently it works fine:
However the last message is still being replayed automatically after a dashboard tab switch. As a result the last contextmenu appears again after a tab switch:
Thierry do you perhaps have any advice about how I could workaround this?
Thanks a lot!!!
Not only the last contextmenu appears after a tab switch, but every contextmenu that was ever opened appears after a tab switch. It is also a cumulative effect. You open one, switch tabs, one appears. You open a second one (after the first one closed automatically after a set timeout), switch tabs, 2 appear and so on. I really hope this can be fixed.
That id indeed verh inconvenient. Will need to find some time then to figure out why the dashboard's persistantFrontEndValue doesn't work in that case...
I have the impression that this is caused pure on the client-side.
I click on a shape in the SVG node, and the contextmenu appears. Indeed now I arrive on all my breakpoints (in the dashboard's ui.js file) on the server side, and the message is not added to the replayMessage array. So the persistantFrontEndValue parameter seems to do the job well.
I switch to another dashboard tabsheet
I switch back to the original tabsheet where my svg & contextmenu is located. At that moment I indeed get again a message on the client:
But I didn't arrive on my server-side breakpoints. So it seems that somehow the client replays the messages. I have installed today the dashboard from source code, because I hoped to be able to debug the main.js file. But from the call stack (see above screenshot) I only see minified stuff
Does anybody have a clue how I could try to find the root cause?
Because I'm stuck at the moment ...
Hi @BartButenaers .
I cant figure it out either but adding this slight hack seems to contain it...
console.log("ui_context_menu: msg already seen - exiting!")
msg._ui_cm_already_seen = true;
@nrbrt would you be willing to test this?
If you could find a file named
context_menu.js in your node-red folder like this.
context_menu.js in a text editor
- Paste the code (in previous post) the as shown in the image (above)
- Restart node-red
It would be most helpful for you to test this.
the modification works for me but I will have different hardware, different flow, different browser, different OS, etc etc.
Let us know.
It will be under
Oh my god.
I tried this a few months ago with the original replay problem, but it didn't work at the time being. Indeed because when the server replays the messages, it has no use to change the message on the client (since you get the original unchanged from the server). But if the client replays it, this little trick indeed seems a good workaround. After debugging the whole flow this morning, it seems I was brain dead at the moment I had figured out that the client caused the replay
Ofcourse I am willing to test it. I am on it now and will keep you posted.
Thanks alot for your effort!
It works like a charm! That is truly awesome!
Thanks for testing.
@BartButenaers, I'll update the repo and publish an update to NPM of you have no objections.
Hi, I have published an update that contains this fix.
Sorry for not responding before but I've been very busy on other projects since several weeks or so...
Fortunately it seems you have found a solution to your problem so that's fine.
From what I understand in this thread, you solved it by telling to the client to do nothing if same msg appears again in scope.watch, that's fine but still I don't understand why this msg appears again ?
Nevertheless looking in the network debug panel from the browser, the persistantFrontEndValue seems to work as expected as the second msg doesn't seem to come from the socket connected to backend...
If someone knows what is really happening (why the client seems to generate this second msg) and could explain here, I would be happy to learn.
Indeed it is a workaround and not a fix. But it works fine since it is exactly the same msg instance over and over again.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.