[BUG] Crash when monitor turned off

tsvallender commented 3 months ago

Checklist before submitting an issue

[X] I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
[X] I have specifically verified that this bug is not a common user error
[X] I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Description of the bug

Turning off the monitor causes eww to crash.

Reproducing the issue

If eww is running and the monitor is turned off, when turned back on eww will have crashed.

From the logs:

 2024-08-16T08:13:31.265Z INFO  eww::app        > Closing gtk window bar

(eww:86616): GLib-GObject-CRITICAL **: 09:13:31.265: ../gobject/gsignal.c:2685: instance '0x564390eb3d80' has no handler with id '92'
 2024-08-16T08:13:31.265Z ERROR eww::error_handling_ctx > Failed to send success response from application thread

Caused by:
    channel closed

This seems unrelated to config, I’ve removed my config and replaced it with the barebones config below and still have the issue.

Running eww 0.6.0 on openSUSE.

Config:

(defwidget bar [] (music))
(defwindow bar
  :monitor 0
  :windowtype "dock"
  :exclusive true
  :geometry (geometry :x "0%"
                      :y "0%"
                      :width "90%"
                      :height "10px"
                      :anchor "top center")
  :reserve (struts :side "top" :distance "100px")
  (bar))

(defwidget music []
  (box :class "music"
       :orientation "h"
       :space-evenly false
       :halign "center"
    {"hello"}))

Expected behaviour

No response

Additional context

No response

cstruck commented 2 months ago

can confirm. whenever I turn off my monitor the eww window crashes

elkowar commented 1 month ago

is this happening on wayland or on X11? Is it actually related to the monitor, or is it the entire computer going to sleep? If wayland, we might need to do some explicit work to catch this sort of thing, Idk exactly how compositors deal with monitors vanishing and popping up

cstruck commented 1 month ago

oh sry, should have added that. Yeah, its wayland.

it crashes with

(eww:10221): GLib-GObject-CRITICAL **: 15:44:02.137: ../glib-2.78.6/gobject/gsignal.c:2777: instance '0x562307bb3e30' has no handler with id '180'
 2024-10-11T13:44:02.137Z ERROR eww::error_handling_ctx > Failed to send success response from application thread

Caused by:
    channel closed
 2024-10-11T13:44:02.137Z INFO  eww::app                > Closing gtk window win1

(eww:10221): GLib-GObject-CRITICAL **: 15:44:02.137: ../glib-2.78.6/gobject/gsignal.c:2777: instance '0x562307cff0a0' has no handler with id '313'
 2024-10-11T13:44:02.137Z ERROR eww::error_handling_ctx > Failed to send success response from application thread

Caused by:
    channel closed

cstruck commented 1 month ago

ah, its when I manually turn off my monitor either by unplugging or just hitting the poweroff button

elkowar commented 1 month ago

I'll try to investigate within the next few days 👍🏻 Thanks for the report!

ayanwx commented 3 weeks ago

I think this issue has more to do with Wayland or hyprland.

I'm using hyprland, and when I turn my monitor off, the active workspace gets set to workspace 6 even though I have only 5 workspaces configured. Which might cause eww to crash?

andi242 commented 6 days ago

I ran into this as well on wayland/hyprland. 2 monitor setup with DP-3 and HDMI-A-1 attached.

What I tried is to start eww with eww open bar --screen=$(hyprctl activewindow -j | jq '.monitor') in hyprland.conf.

while eww is running, do a

(defpoll screen
  :interval "3s"
  :initial "a"
  "scripts/monitor.sh"
)

monitor.sh is

#!/bin/bash

count=$(hyprctl monitors -j | jq '.[].name' -r | wc -l)

main=DP-3
side=HDMI-A-1

if [[ "$((count))" -eq "2" ]]; then
  echo $main
else
  echo $side
fi

but it seems like once the defwindow is initialized it can't be changed. ERROR eww::error_handling_ctx > Variable screen not scope

in addtion, when disabling one monitor eww crashes which prevents screen from updating anyways.

2024-11-26T08:30:29.664Z INFO  eww::app                > Closing gtk window topbar

(eww:558806): GLib-GObject-CRITICAL **: 09:30:29.664: ../gobject/gsignal.c:2684: instance '0x5632f7bb2d30' has no handler with id '2703'
 2024-11-26T08:30:29.664Z ERROR eww::error_handling_ctx > Failed to send success response from application thread

wrapping up: this appears not to be a root cause in eww, but it may be handled by eww if the error is catched with a reload or something? I lack the skills to do a PR, though. :grimacing:

andi242 commented 6 days ago

Found a good hint here: https://github.com/nwg-piotr/nwg-panel/issues/344#issuecomment-2484997858 and adapted it to a script that fits my setup

udev-check.sh

#!/bin/bash

main=DP-3 # name of main display
side=HDMI-A-1 # name of secondary

# listen to udev events
udevadm monitor --udev --subsystem-match=drm | while read -r line; do
  if echo "$line" | grep -q "change"; then
    echo "monitors changed"
    count=$(hyprctl monitors -j | jq '.[].name' -r | wc -l)
    echo "$count devices available"
    if [[ "$((count))" -eq "2" ]]; then
      echo $main
      eww open mainbar --screen=$main
    else
      echo $side
      eww open mainbar --screen=$side
    fi
  fi
done

hyprland.conf

exec-once = eww open mainbar --screen=DP-3
exec-once = udev-check.sh

so every time the udev event is fired, the script checks the number of monitors that are available. if 2 monitors are available, start the bar on the main display, if not start it on the secondary.

since wayland is shifting IDs around when displays become unavailable, the display name is necessary to get consistent placement. I assume that every wayland statusbar has this problem and this is a workaround for me until this has been sorted out.

cstruck commented 6 days ago

My guess would be that eww is trying trough gtk to draw on a window or display which is not available anymore which causes the gtk function to throw an error which eww does not catch. the question would be if the monitor is restored is it still the same window / canvas or whatever which eww would try to draw on. Since I have no clue about gtk internally works this is just a guess.

So the question would be what would eww need to do to not crash if the display it tries to draw on is gone and reappears sometime later

elkowar / eww