Resize path field on resizing editor panel

Core Development Feature Requests
1

Hi there,

Something I just came across because I have a particular long file name that I want to save. So I thought I'd resize the edit panel to make the file name input file larger:

Screen Recording 2026-01-05 at 07.57.00-2

Notice the name input field expands when I resize but not the path. Is that because it's a typedinput field and not just an input field? It would be nice if the path field also expanded for long file paths ...

Cheers!

1 Like
2

There are still quite a few CSS oddities in Editor config panels to be honest and too many fixed pixel sizes. I've taken to using my own CSS for my own nodes.

3

Not just CSS oddities either, field placements are not consistent.

For example the Name field is generally at the top of a node config dialog, but for some nodes, eg debug, it's at the bottom & for some such as http-request its not even visible without scrolling down.

And in contrib nodes:
@flowfuse/node-red-dashboard radio-group has options value and label
while button-group has label before value

4

To be fair, that is down to the node designer. I put the name towards the bottom if it isn't very important to the node. UX would dictate that the most important fields should generally be at the top.

The default styling could certainly do with a brush-up though. There is still a lot of "boiler-plate" inline styling and several styles use px sizing. A boost to modern grid/flex styles along with the use of LightningCSS to control browser support limits really would save every node developer a lot of time and effort.

5

And all I wanted was a extendable path field .... had I known what was in the can, I would have never pulled the cat out of it. :wink:

6

Rule #1 - when pulling cats out of cans, make sure you feed them straight away! :rofl:

20260105-1124-09.9771416

As you can see, it is possible to get adjusting fields.

image
image940Ă—136 10.6 KB

2 Likes
7

Wow, that's simple! Can we get that into production? Or is there something that prevents that?

8

That's probably one for Steve or Nick to comment on.

Don't see why not though. The calc() CSS function has been baseline available since around 2013.

9

Lack of a Pull Request generally :slight_smile:

Re Name placement - Originally (way back) - we mostly placed the Name field at the bottom of the panel - because (as @TotallyInformation points out) the name already had a default and was more optional for users to customise...

Over time that changed as a) we wanted to encourage users to set the name to make finding nodes easier and b) because panels got so large the name moved off the bottom... so they started to migrate position to the top instead...

10

Ouch! What was that? A hint just hit me.

2 Likes
11

Indeed a hint - but hey I'm in a good mood so far this year :slight_smile: Let TypedInput width be calculated - but forced by dceejay · Pull Request #5422 · node-red/node-red · GitHub

But yes - a long term chore would be to go through all the core nodes and make them more consistent (as far as possible) - and better use CSS styles, and position of name filed (see other thread) - etc....

12

Let's hope it remains so!

It really would have taken me way too much time just to find the one single support where that CSS lives ... let's hope Nick is a good mood too :wink:

Thanks for the doing work - again!

1 Like
13

My only pause is that modifying the default styling of the TypedInput will have wide-ranging impacts wherever it is used - and it's used in lots of places. There is a high potential for this fix causing undesirable side-effects we then spend lots of time squashing. As much as inline css is distasteful, that may be the safer option to address the specific request relating to the file nodes.

14

Would you pick this up as a routine fix for the next release? I mean if this is a one-line inline CSS fix that would probably be appreciated by others ... at least no one has come out and said "no, I want to keep the old behaviour" (if so, then now is the time!)

#AskingForAFriend

15

Absolutely - a fix to the file nodes can and should be done for the next release. I'm putting the next 4.1.x maint release together at the moment.

1 Like
16

Out of curiosity, would this be the change --> Comparing node-red:master...gorenje:patch-5 · node-red/node-red · GitHub

17

Doing some quick tests by adding the calc width in the browser does cause 1 issue I found:

image
image1035Ă—486 17.1 KB

The inject node has 2 typedInput fields side-by-side that do not correctly overflow.

My recommendation would be to add the calculated width to .red-ui-typedInput-container without the !important and then slowly go through the existing nodes to remove the manual sizing unless needed. That should be entirely safe.

18

Nick, I wonder if you would consider a hackathon style event where people can sign up to work on the editor panel for a single core node?

It might be a great way to get more people involved and more confident at working on Core, something I know has been difficult.

19

All 5758 of them?

There's a quick pragmatic fix for 4.1.x to get this done quickly. There's a bigger piece of work for it to be done properly - which will need prioritising against all of the other work.

20

So the net is.... just do a spot fix for the file nodes ?
or do the fix (with !important) and also tweak a few nodes that may need fixing ?