[Announce] node-red-contrib-ui-contextmenu

I have updated the info panel and the readme file, and published version 1.0.9 on npm:


Seems the ws package is a dependency of some other node that you have installed, and that ws package has peer dependencies (which are not installed automatically anymore since npm version xxx). Cannot do anything about that, since the context-menu node has no dependencies...

1 Like

Sorry to be the one to say (again!!) @BartButenaers but it's not working here.. :slightly_frowning_face:

I've configured the node as per the readme, using a simple fixed menu, but it does not appear in the dashboard group.

Checking my browser console, I see the following;

If I try and load https://nodered.digitalnut.co.uk:8443/ui/ui_context_menu/contextmenu.js?_=1582707759368 in a browser (as per the 401 error above) I get a prompt for auth. If I enter my user/password, then the contents of this file is then displayed.
The same applies with https://nodered.digitalnut.co.uk:8443/ui/ui_context_menu/contextmenu.css, again I'm prompted for auth.

I'm assuming that this is because I've password protected the Node-RED editor, admin API & the node-defined HTTP endpoints using adminAuth & httpNodeAuth (remember we had similar issues with node-red-contrib-xterm).

Hey Paul,
pfffff ...
But the xterm problem was about the admin endpoint with needspermission. For the UI node we use RED.httpNode and that doesn't use needspermission. I have no idea at the moment ...
And my lunch break is over ...

Hey Paul (@Paul-Reed) ,
Sorry for keeping you waiting...
Hopefully somebody can give me a tip where to start searching, because I have no idea :woozy_face:
In my context_menu.js file, I publish my third party (js and css) files to the browser like I do in all my other UI nodes:

    // By default the UI path in the settings.js file will be in comment:
    //     //ui: { path: "ui" },
    // But as soon as the user has specified a custom UI path there, we will need to use that path:
    //     ui: { path: "mypath" },
    var uiPath = ((RED.settings.ui || {}).path) || 'ui';
    // Create the complete server-side path
    uiPath = '/' + uiPath + '/ui_context_menu/*';
    // Replace a sequence of multiple slashes (e.g. // or ///) by a single one
    uiPath = uiPath.replace(/\/+/g, '/');
    RED.httpNode.get(uiPath, function (req, res) {
        var options = {
            root: __dirname + '/lib/',
            dotfiles: 'deny'
        res.sendFile(req.params[0], options)

I assume that the uiPath is determined correctly, since you can access the RED.httpNode endpoint (after you have entered your credentials).

I'm in no rush :wink: - I'm using a ui-dropdown node in the meantime, but it's a bit ugly!

For info, my node-RED is script installed

  • Node-RED version: v1.0.3
  • Node.js version: v10.19.0
  • Dashboard version 2.19.4
  • Oracle Linux 4.14.35

But other than adding adminAuth & httpNodeAuth, it's a vanilla installation, so assume others with NR security enabled would have the same problem.

I don't know if it helps, but I've just removed all the security settings in node-RED, and the contextmenu node functions without errors.

Adding them back, it appears that when httpNodeAuth is enabled, that is what causes the 401 error messages.

1 Like

Could it be possibly related to the (unsolved) situation seen here?

Hi Lena,
When I set the httpNodeAuth in my settings.js file, it also fails for me. I'm now trying to debug it. Below is the call stack of my endpoint (i.e. the happy path), in case the httpNodeAuth is not activated:

So somewhere in between it fails to access the endpoint...

If I can find a moment tomorrow I’ll compare the uibuilder stack with this one. See where it goes out on both... I’m curious for sure what’s causing this


For my issue, this has now been resolved. see Node-red-ui-table fails when httpNodeAuth enabled


Hi Bart, Hi Steve,

I just observed a strange thing. When I do a page refresh in chrome 80.0.3987.122 (64-Bit) on windows 10 (not tested elsewhere) my two context menus pops up on the last position they where used:

perhaps it has something to do with the dashboard replaying the last message when a session connects, because no message is triggering this (checked with debug nodes). Timers are not started / working, only after I hovered over the menus once.

I'm using Node-RED 1.0.3 and dashboard 2.19.4 on windows 10.

BTW: It`s always the last position where it was triggered the last time:

I have the same on Ios, when I change to a tab that contains context menus all context menus I used the last time I was on the tab are displayed until i either tap them away or do a refresh with ui control.

Last week I have created a new version of the contextmenu node, which should have solved that issue ( in combination with dashboard 0.19.4 or above). You are using the latest contextmenu node version?

You can find more details about the solution here.

1 Like

Is there anyway the menu can always be on the uppermost layer.


Can't that be done (@BartButenaers) by adding a ridiculously high z-index on the css?

Hi Paul,
Indeed like @afelix says the z-index could solve it. However I had some problems with that in the past, in combination with other style elements (e.g. position)...

But let's try.... I have added it on the surrounding DIV element:

<div id='div_" + node.config.id + "' style='z-index: 999999;' ...

You can install it directly from my Github repository:

npm install bartbutenaers/node-red-contrib-ui-contextmenu
[opc@digitalnut .node-red]$ npm install bartbutenaers/node-red-contrib-ui-contextmenu
npm WARN Master_flow@0.0.1 No repository field.
npm WARN Master_flow@0.0.1 No license field.

+ node-red-contrib-ui-contextmenu@1.0.9
updated 1 package and audited 1250 packages in 13.621s

15 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

Still the same I'm afraid in incognito browser.

@BartButenaers @Paul-Reed, coming back to the issue from this last weekend for a moment... Bart, does your node add things to the appcache of the dashboard, or is it compiled/minified to it? Paul, can you try resetting it again through chrome://... like you did before and see if it changes anything?

No still the same Lena.

Okay, means I can trash that line of thought.