Debug window scroll default to bottom (newest messages)

Core Development Feature Requests
1

It seems to me that the debug window has 2 different scrolling behaviors, depending on when it is opened relative to the accumulated debug messages:

A. If you open the Debug window when less than 1 "page" of debug messages have accumulated, or if you open the Debug window, then click the "clear log" (trash can) button: when it fills with debug messages, the Debug window scroll "thumb" will default to the bottom end of the scrollbar, and the newest Debug message will always appear at the bottom of the window. This is the way I would like the Debug window scrolling to always function.

B. If you open the Debug window after more than 1 page of debug messages have accumulated (say, after launching NR in browser, and a flow has auto-started and generated a bunch of debug messages), the Debug window scroll thumb will default to the top end of the scrollbar, and the oldest Debug messages will be "pegged" in the window, until finally the Debug window message buffer is full, and newer messages start scrolling into view.

The latter behavior is undesirable. If you are paying close attention, you will notice that the timestamps of the debug messages scrolling into view are older - not the latest debug messages. And of course, after you notice this, you can simply drag the scroll thumb down from the top to the bottom of the scrollbar, so you get the "A" behavior, and always see newest debug messages at the bottom of the window.

But I have been bitten by "B" more than once. I make changes to a flow, deploy it, and start watching the debug window - but it will appear as if my change has not taken effect, because I am seeing old debug messages scroll into view; not the new debug messages associated with my flow changes.

It is annoying to have to drag the scroll thumb to the bottom when "B" happens.

Could the Debug window scroll behavior be changed, to always default to behavior "A" ?

2

I think that the normal output is that the debug log will always scroll unless you scroll back away from the end of the log.

In that case, you absolutely don't want the thing scrolling every time a new output appears because it is most likely that you are trying to read something on screen.

If you scroll back down to the bottom, the normal scrolling behaviour should restart.

Is that what is happening?

3

No, that's not quite what I mean. I have pasted a trivial example flow below (sorry - as a newbie, cannot upload attachments yet) - random.json - which just outputs a random integer in a debug message once per second.

  1. Import the flow random.json, deploy it
  2. Close NR editor webpage in browser
  3. Open NR editor webpage in browser; random.json will start, but debug window will not be open by default
  4. Wait 20 seconds or so, to allow debug messages to fill the (not yet visible) debug window
  5. Click on the Debug messages button
  6. The Debug window will be full of "random value" debug messages. Scroll thumb will be at TOP of scrollbar; topmost debug message will be oldest. Nothing will be changing or scrolling now, but the scroll thumb will gradually get smaller and smaller as the debug message buffer fills up.
  7. Finally, when the debug message buffer is full, newer debug messages will start scrolling in from the bottom. BUT these are not the NEWEST debug messages - i.e., the bottom-most debug message is NOT the most recent one. They are old debug messages that have accumulated in the debug message buffer, and are now scrolling to the top of the debug window.

This is state "B" I describe above. Note that I have not touched the scrollbar (the "thumb" slider control).

Your reply does suggest to me another solution to "B", besides ALWAYS defaulting to scroll from the bottom: a user setting, to indicate whether they want the Debug window to always automatically scroll from the bottom by default (or not) - in ALL cases, including A&B above. Of course, if the user moves the scroll thumb (or clicks up or down in the scrollbar), it should stop scrolling and stay at the new position.

Some apps call this "auto-scroll" - such as Wireshark: "Automatically scroll to the last packet during a live capture"

random.json:

[
    {
        "id": "9a83b382.5f674",
        "type": "tab",
        "label": "random",
        "disabled": false,
        "info": ""
    },
    {
        "id": "7ec7126a.134edc",
        "type": "inject",
        "z": "9a83b382.5f674",
        "name": "",
        "topic": "",
        "payload": "",
        "payloadType": "date",
        "repeat": "1",
        "crontab": "",
        "once": true,
        "x": 130,
        "y": 140,
        "wires": [
            [
                "95c6392e.0e1928"
            ]
        ]
    },
    {
        "id": "95c6392e.0e1928",
        "type": "function",
        "z": "9a83b382.5f674",
        "name": "Get random int (100)",
        "func": "msg.payload = {\n  data: getRandomInt(100)\n};\n\nreturn msg;\n\nfunction getRandomInt(max) \n{\n    return Math.floor(Math.random() * Math.floor(max));\n}\n ",
        "outputs": 1,
        "noerr": 0,
        "x": 320,
        "y": 200,
        "wires": [
            [
                "3b803d68.ae9d42"
            ]
        ]
    },
    {
        "id": "3b803d68.ae9d42",
        "type": "debug",
        "z": "9a83b382.5f674",
        "name": "random value",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "payload",
        "x": 520,
        "y": 260,
        "wires": []
    }
]
1 Like
4

Please make sure that you put backticks around your code so that we can make sense of it. Usually triple backticks for long code.

5

Thanks for the suggestion. Done.

But please note - the above flow was just meant to be a trivial example of a flow that generates frequent debug messages; there is nothing special about the flow.

6

So that "B" behavior you are describing is because there is a limit to how many debug msgs can be shown in the sidebar. Julian is correct, that the scrolling will follow the incoming messages IFF the sidebar was previously scrolled all the way to the bottom. Once you scroll backwards, it stays where you left it, so you can keep reading... most teminal windows work the same way, unless you select the "Always scroll on new input" option. Perhaps that is what you are asking for?

When you scroll backward, and new msgs keep arriving, you noticed that the scroll bar handle shrinks -- because it represents the fraction of the whole stream that you are seeing. Once you receive enough msgs to exceed the node-red limit, then the oldest msgs get removed from the stack... so yes, if you watch long enough without moving the scroll bar you will see the top msg disappear, and the ones below it move up. I believe it's working as designed, and as it should.

1 Like
7

Whilst everything @shrickus says is correct... the subtlety about the scenario that is being discussed here. The key point is what happens when the Debug tab is not open.

If the Debug tab is open and you haven't scrolled back up at all, it will scroll as new messages arrive. If you switch to another tab, let some more messages arrive and then switch back - the Debug tab has not continued to scroll to show the new messages - it is still where it was when to switched tabs. So you have to manually scroll down.

Now, I would argue that is an entirely valid behaviour because you don't miss anything. But I can also see for some cases you don't care about what you missed, you want to see the new stuff coming in.

There are various ways we could go about accommodating both cases. For example:

  • add a tick box to always scroll to the bottom as new messages arrive (which could auto-untick if you manually scroll up, and auto-tick if you scroll to the bottom)
  • add a button to jump to the bottom of the debug messages - to save scrolling (and could have a keyboard short-cut assigned)
8

I agree that this behaviour is not ideal -- when i have a tail -f file.log process running, and I iconify the window, it shows the last lines when I re-open it. I would not expect it to stay where it was, unless I had previously (manually) moved the scrollbar back.

FWIW, I like this first option...

9

FWIW - I prefer the second... checkboxes = yet more state to hold somewhere... and would need text to explain it and waste more screen estate.

10

I think the first is more versatile but the 2nd is certainly simpler.

I'd be happy either way I think. Though my initial preference was for the checkbox.

11

Ah, spoken like a "maintainer" or something... sure, sure. What if it's just an option in the settings (as opposed to changing the sidebar ui)?

12

Well there is room at the bottom for a button

image

1 Like
13

Hi again - although I'm the newbie here, my vote would be for option 1 (check box for "auto-scroll from bottom") or an option in the settings.

In my opinion, option 2 does not address one subtle aspect of the problem, which I think I have still not explained clearly:

Actually - in the case I'm describing, it will not be "still where it was". In my step "7" above, after the debug buffer is full, it will start scrolling messages into view. And if you don't look closely, it looks "just like normal" , with debug messages constantly scrolling by. But you are not seeing the LATEST messages - you are seeing old messages scroll into view.

When you are focused on some challenging JS bug in a flow, you may not notice that the scroll thumb is all the way at the top, and you are looking at old messages scrolling by, not new messages reflecting your last tweak to a flow.

I don't want to have to notice or discover this subtle difference, then go hit a button to scroll to the bottom. I would much prefer it is a settable option, so I CAN'T make the mistake of assuming I'm looking at the latest debug messages.

Let me see if I'm allowed to upload attachments now...

Here is the "normal" case A, when you have the debug window all or most of the time, and/or you have clicked the "clear log" button. It automatically positions the scroll thumb at the bottom, and new messages appear at the bottom of the window:

debug_scroll_case_A
debug_scroll_case_A1029Ă—671 31.6 KB

Here is the "problem" case B, when the debug window has filled with messages BEFORE you open the debug tab. It automatically positions the scroll thumb at the top; the window will be static with oldest message at the top, until the buffer is full and old messages start scrolling in from the bottom of the window:

debug_scroll_case_B
debug_scroll_case_B1029Ă—668 32 KB

The scroll thumb position is not instantly obvious, when you are focusing on the messages scrolling by. And in case B, you are looking at old messages, possibly without realizing it.

Please note, in NEITHER case have I touched the scroll thumb or scrollbar in any way. I am describing the DEFAULT scrollbar behavior of the debug window.

1 Like