Title doesn't update when foot window is hidded (i.e. sway stacked/tabbed layout) #591

Closed
opened 4 months ago by gorrillaribs · 9 comments

As the title says, when foot is part of a tabbed or stacked container on sway, but the program running updates/changes it's title (i.e. ncmpcpp / cmus plays a different song, or a job finishes and the shell sets the title again) then the window title won't update until foot is focused again. Could this a foot issue, or should I be looking elsewhere (sway or my shell maybe?).

Thanks in advance!

As the title says, when foot is part of a tabbed or stacked container on sway, but the program running updates/changes it's title (i.e. ncmpcpp / cmus plays a different song, or a job finishes and the shell sets the title again) then the window title won't update until foot is focused again. Could this a foot issue, or should I be looking elsewhere (sway or my shell maybe?). Thanks in advance!
dnkl added the
bug
label 4 months ago
Owner

Looks like a bug in foot (Alacritty and Kitty works as expected).

Looks like a bug in foot (Alacritty and Kitty works as expected).
Owner

Ok, so title updates are currently throttled to the frame rate. This was basically done to prevent malicious applications from spamming title changes, which would fill up the Wayland socket and thus getting us terminated.

This means the title wont get updated until the compositor sends us a frame callback. Something Sway never does when a window is hidden (makes sense - a hidden window doesn't need to be redrawn).

The simple fix is simply to stop throttling title updates and just do the Wayland call immediately. This'll probably work in all real world cases. But maybe not. This needs to be tested, and if possible, a different throttling mechanism used.

Ok, so title updates are currently throttled to the frame rate. This was basically done to prevent malicious applications from spamming title changes, which would fill up the Wayland socket and thus getting us terminated. This means the title wont get updated until the compositor sends us a frame callback. Something Sway never does when a window is hidden (makes sense - a hidden window doesn't need to be redrawn). The simple fix is simply to stop throttling title updates and just do the Wayland call immediately. This'll probably work in all real world cases. But maybe not. This needs to be tested, and if possible, a different throttling mechanism used.
Owner

Tested running, with throttling disabled

while true; do echo '\e]0;new title\e\\'; done

It didn't seem to cause any problems. Sway usage went from ~0% to 22%, compared to when we throttle. Both foot and zsh usage was the same: pegged at ~100%.

Let's see if we're still ok if I do the same thing in a C program...

Tested running, with throttling disabled ```sh while true; do echo '\e]0;new title\e\\'; done ``` It didn't seem to cause any problems. Sway usage went from ~0% to 22%, compared to when we throttle. Both foot and zsh usage was the same: pegged at ~100%. Let's see if we're still ok if I do the same thing in a C program...
Owner
#include <stdio.h>
#include <assert.h>
#include <unistd.h>

#include <sys/stat.h>
#include <fcntl.h>

int main(int argc, const char *const *argv)
{
    int tty = open("/dev/tty", O_RDWR);
    assert(tty >= 0);

    while (1) {
        const char set_title[] = "\033]0;title\033\\";
        write(tty, set_title, sizeof(set_title));
    }

    return 0;
}

Resulted in Sway using 100% CPU for a while, and then:

Error sending request: Resource temporarily unavailable

... and we're dead: terminal was unresponsive and I had to kill -9 it.

```c #include <stdio.h> #include <assert.h> #include <unistd.h> #include <sys/stat.h> #include <fcntl.h> int main(int argc, const char *const *argv) { int tty = open("/dev/tty", O_RDWR); assert(tty >= 0); while (1) { const char set_title[] = "\033]0;title\033\\"; write(tty, set_title, sizeof(set_title)); } return 0; } ``` Resulted in Sway using 100% CPU for a while, and then: ``` Error sending request: Resource temporarily unavailable ``` ... and we're dead: terminal was unresponsive and I had to `kill -9` it.
Owner

But perhaps we should just ignore this. There are many ways in which a program can hang or freeze a terminal.

But perhaps we should just ignore this. There are many ways in which a program can hang or freeze a terminal.
Poster

Thanks a ton for the fix! I just tried the title-update branch, seems to fix things nicely :) - doesn't seem to be any change in cpu usage when a program idles/doesn't change the title either, I've been using the branch all day with no issues.

I also got the same behaviour from the c program, but that also shows up in alacritty & behaves similarly in xterm (doesn't pin a core at 100%, but increases cpu usage & freezes xterm, requiring a kill -9), so it doesn't seem to be a foot specific issue.

Could this be a good fit for the 'tweak' config section? It seems like something that should be togglable if someone's expecting to deal with an untrusted program (over ssh?). Maybe either a timer update/frame update switch or a configurable timer? I'd be happy to write up a patch implementing that if that sounds useful

Thanks a ton for the fix! I just tried the title-update branch, seems to fix things nicely :) - doesn't seem to be any change in cpu usage when a program idles/doesn't change the title either, I've been using the branch all day with no issues. I also got the same behaviour from the c program, but that also shows up in alacritty & behaves similarly in xterm (doesn't pin a core at 100%, but increases cpu usage & freezes xterm, requiring a kill -9), so it doesn't seem to be a foot specific issue. Could this be a good fit for the 'tweak' config section? It seems like something that should be togglable if someone's expecting to deal with an untrusted program (over ssh?). Maybe either a timer update/frame update switch or a configurable timer? I'd be happy to write up a patch implementing that if that sounds useful
Owner

I don't think this is something that warrants an option; either we throttle, or we don't :)

Like I said, it might be fine to ignore throttling, and just crash/hang if an application is flooding us with title updates. But doing so would mean a regression, compared to previous versions of foot.

Let me turn this question around: what do you perceive the problems are with using a timer to throttle title updates?

I don't think this is something that warrants an option; either we throttle, or we don't :) Like I said, it might be fine to ignore throttling, and just crash/hang if an application is flooding us with title updates. But doing so would mean a regression, compared to previous versions of foot. Let me turn this question around: what do you perceive the problems are with using a timer to throttle title updates?
Poster

I don't see any problems with using a timer, it seems to be how other terminal emulators handle it - I just figured someone might want the ability to restore the old behaviour, but I don't know how much a program being able to hang a terminal is a problem, as you said :)

I don't see any problems with using a timer, it seems to be how other terminal emulators handle it - I just figured someone might want the ability to restore the old behaviour, but I don't know how much a program being able to hang a terminal is a problem, as you said :)
Owner

Ah, I think I understand what you mean. The thing is, there shouldn't really be any difference in behavior, as perceived by both users and applications.

Both the frame callback and timer do exactly the same thing - ensure the title updates aren't sent to the compositor "too often". None of them block titles, or prevent them from being set - the application's last title update is always set. It's just that it may be delayed (by an amount smaller than the frame iterval - i.e. the user wont even know the update was delayed).

The only thing I have against using a timer is that it adds complexity. It's much easier to just ignore the problem :)

Ah, I think I understand what you mean. The thing is, there shouldn't really be any difference in behavior, as perceived by both users and applications. Both the frame callback and timer do exactly the same thing - ensure the title updates aren't sent to the compositor "too often". None of them _block_ titles, or prevent them from being set - the application's last title update is **always** set. It's just that it _may_ be delayed (by an amount smaller than the frame iterval - i.e. the user wont even know the update was delayed). The only thing I have _against_ using a timer is that it adds complexity. It's much easier to just ignore the problem :)
dnkl closed this issue 4 months ago
dnkl referenced this issue from a commit 4 months ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.