[BUG] Panic with notifier_host #1202

MonaMayrhofer · 2024-09-20T07:08:06Z

Checklist before submitting an issue

I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
I have specifically verified that this bug is not a common user error
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

When trying to create a window with the systray widget, eww panics on my system.

thread 'main' panicked at /home/nionidh/ThirdParty/eww/crates/notifier_host/src/item.rs:64:25:
byte index 6 is out of bounds of `:1.22`
stack backtrace:
   0:     0x55555710d2f5 - std::backtrace_rs::backtrace::libunwind::trace::h23054e327d0d4b55
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/../../backtrace/src/backtrace/libunwind.rs:116:5
   1:     0x55555710d2f5 - std::backtrace_rs::backtrace::trace_unsynchronized::h0cc587407d7f7f64
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55555710d2f5 - std::sys_common::backtrace::_print_fmt::h4feeb59774730d6b
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/sys_common/backtrace.rs:68:5
   3:     0x55555710d2f5 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd736fd5964392270
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x55555713aa0b - core::fmt::rt::Argument::fmt::h105051d8ea1ade1e
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/fmt/rt.rs:165:63
   5:     0x55555713aa0b - core::fmt::write::hc6043626647b98ea
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/fmt/mod.rs:1168:21
   6:     0x5555571089ef - std::io::Write::write_fmt::h0d24b3e0473045db
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/io/mod.rs:1835:15
   7:     0x55555710d0ce - std::sys_common::backtrace::_print::h62df6fc36dcebfc8
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/sys_common/backtrace.rs:47:5
   8:     0x55555710d0ce - std::sys_common::backtrace::print::h45eb8174d25a1e76
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/sys_common/backtrace.rs:34:9
   9:     0x55555710e619 - std::panicking::default_hook::{{closure}}::haf3f0170eb4f3b53
  10:     0x55555710e3ba - std::panicking::default_hook::hb5d3b27aa9f6dcda
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panicking.rs:298:9
  11:     0x55555710eab3 - std::panicking::rust_panic_with_hook::h6b49d59f86ee588c
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panicking.rs:795:13
  12:     0x55555710e994 - std::panicking::begin_panic_handler::{{closure}}::hd4c2f7ed79b82b70
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panicking.rs:664:13
  13:     0x55555710d7b9 - std::sys_common::backtrace::__rust_end_short_backtrace::h2946d6d32d7ea1ad
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/sys_common/backtrace.rs:171:18
  14:     0x55555710e6c7 - rust_begin_unwind
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panicking.rs:652:5
  15:     0x5555558351a3 - core::panicking::panic_fmt::ha02418e5cd774672
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/panicking.rs:72:14
  16:     0x55555713e2bf - core::str::slice_error_fail_rt::he2f060e147dc8062
  17:     0x555555835a0a - core::str::slice_error_fail::he28d4c84515d0ab6
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/str/mod.rs:89:5
  18:     0x555556d99c14 - core::str::traits::<impl core::slice::index::SliceIndex<str> for core::ops::range::Range<usize>>::index::hef84cb88a94c326f
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/str/traits.rs:244:21
  19:     0x555556d9a007 - core::str::traits::<impl core::ops::index::Index<I> for str>::index::h0ae2601158576f50
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/str/traits.rs:62:9
  20:     0x555555bb0776 - notifier_host::item::Item::from_address::{{closure}}::hedcf549c658b82b8
                               at /home/nionidh/ThirdParty/eww/crates/notifier_host/src/item.rs:64:25
  21:     0x555555ad8d7c - notifier_host::host::run_host::{{closure}}::hc6185855b97afee9
                               at /home/nionidh/ThirdParty/eww/crates/notifier_host/src/host.rs:91:66
  22:     0x555555b4a200 - eww::widgets::systray::spawn_systray::{{closure}}::h379d91c681c5687f
                               at /home/nionidh/ThirdParty/eww/crates/eww/src/widgets/systray.rs:86:63
  23:     0x555555937b27 - glib::main_context_futures::<impl glib::auto::main_context::MainContext>::spawn_local_with_priority::{{closure}}::h963c5111bb9c1f17
                               at /home/nionidh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glib-0.18.5/src/main_context_futures.rs:564:24
  24:     0x5555570a0a7c - <futures_task::future_obj::LocalFutureObj<T> as core::future::future::Future>::poll::h6414c455ca841a0f
                               at /home/nionidh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-task-0.3.30/src/future_obj.rs:84:18
  25:     0x55555709ee0b - <glib::main_context_futures::FutureWrapper as core::future::future::Future>::poll::hf5157cbeb93e0d93
                               at /home/nionidh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glib-0.18.5/src/main_context_futures.rs:38:44
  26:     0x55555709fa31 - glib::main_context_futures::TaskSource::poll::{{closure}}::{{closure}}::h2e81ec70b8b3230a
                               at /home/nionidh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glib-0.18.5/src/main_context_futures.rs:245:25
  27:     0x5555570ae5a8 - core::ops::function::FnOnce::call_once::h2cde6043c729d0f0
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/ops/function.rs:250:5
  28:     0x5555570a49b7 - <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h0287346224293b4b
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/panic/unwind_safe.rs:272:9
  29:     0x5555570a01d6 - std::panicking::try::do_call::hcf0f4a4c2b06b0ee
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panicking.rs:559:40
  30:     0x5555570a1b3b - __rust_try
  31:     0x5555570a0134 - std::panicking::try::h783ef43013ddb00e
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panicking.rs:523:19
  32:     0x5555570ac36b - std::panic::catch_unwind::h61d933840aab0acd
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panic.rs:149:14
  33:     0x55555709f6cd - glib::main_context_futures::TaskSource::poll::{{closure}}::h60c5f3c117d5cfae
                               at /home/nionidh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glib-0.18.5/src/main_context_futures.rs:244:31
  34:     0x55555709964b - glib::main_context::<impl glib::auto::main_context::MainContext>::with_thread_default::hf3ab1287bb3c208a
                               at /home/nionidh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glib-0.18.5/src/main_context.rs:154:12
  35:     0x55555709f555 - glib::main_context_futures::TaskSource::poll::h1d8a626e19fe50da
                               at /home/nionidh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glib-0.18.5/src/main_context_futures.rs:236:9
  36:     0x55555709eea2 - glib::main_context_futures::TaskSource::dispatch::h0cebb8129cedcaee
                               at /home/nionidh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glib-0.18.5/src/main_context_futures.rs:74:34
  37:     0x7ffff71310a4 - g_main_dispatch
  38:     0x7ffff71342c7 - g_main_context_iterate_unlocked.isra.0
  39:     0x7ffff7134bcf - g_main_loop_run
  40:     0x7ffff781457d - gtk_main
  41:     0x55555707602e - gtk::auto::functions::main::h9ae9a7a8bf913726
                               at /home/nionidh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/gtk-0.18.1/src/auto/functions.rs:371:9
  42:     0x555555b398b0 - eww::server::initialize_server::h29404a85061120db
                               at /home/nionidh/ThirdParty/eww/crates/eww/src/server.rs:133:5
  43:     0x555555854b5c - eww::run::h9d49cbf8dae08d80
                               at /home/nionidh/ThirdParty/eww/crates/eww/src/main.rs:166:39
  44:     0x555555ab6f08 - eww::main::hfb025801777511aa
                               at /home/nionidh/ThirdParty/eww/crates/eww/src/main.rs:62:9
  45:     0x555555c241bb - core::ops::function::FnOnce::call_once::h92d4b756ed7b7919
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/ops/function.rs:250:5
  46:     0x5555558cf31e - std::sys_common::backtrace::__rust_begin_short_backtrace::h09dfcb5280f56624
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/sys_common/backtrace.rs:155:18
  47:     0x555555abb321 - std::rt::lang_start::{{closure}}::h96c71d80a5d1aeea
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/rt.rs:159:18
  48:     0x5555570fec8d - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hf57beef1b8c334ce
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/ops/function.rs:284:13
  49:     0x5555570fec8d - std::panicking::try::do_call::h65791b6ab5d9b39f
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panicking.rs:559:40
  50:     0x5555570fec8d - std::panicking::try::h5a3dd25e8a379a23
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panicking.rs:523:19
  51:     0x5555570fec8d - std::panic::catch_unwind::he2ce8403bab77de2
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panic.rs:149:14
  52:     0x5555570fec8d - std::rt::lang_start_internal::{{closure}}::h0b55d0da19178545
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/rt.rs:141:48
  53:     0x5555570fec8d - std::panicking::try::do_call::h33cbeb674c7644e0
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panicking.rs:559:40
  54:     0x5555570fec8d - std::panicking::try::h530c58b4c9daadba
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panicking.rs:523:19
  55:     0x5555570fec8d - std::panic::catch_unwind::h92e02677901e11e4
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/panic.rs:149:14
  56:     0x5555570fec8d - std::rt::lang_start_internal::hcee5ed89fc25829a
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/rt.rs:141:20
  57:     0x555555abb2fa - std::rt::lang_start::h91a60a684be38766
                               at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/std/src/rt.rs:158:17
  58:     0x555555ab7bfe - main
  59:     0x7ffff6dbf14e - __libc_start_call_main
  60:     0x7ffff6dbf209 - __libc_start_main@@GLIBC_2.34
  61:     0x555555835d35 - _start
  62:                0x0 - <unknown>

Reproducing the issue

Having the config

(defwindow bar
  :monitor 0
  :windowtype "dock"
  :geometry (geometry :x "0%"
                      :y "0%"
                      :width "90%"
                      :height "10px"
                      :anchor "top center")
  :reserve (struts :side "top" :distance "4%")
  (systray))

in examples/systray/eww.yuck.

Then starting a program that provides systray entries like nm-applet

Then running

RUST_BACKTRACE=full cargo run -- --config ./examples/systray/ --logs --restart open bar

Additional context

I am driving NixOS and Hyprland.
This issue appears on eww main at commit 8661abf, however I assume it would have been around since #743

I will keep investigating this and post updates in here, however if there is any guidace, that would be greatly appreciated as this is my first time within the eww codebase.

The text was updated successfully, but these errors were encountered:

MonaMayrhofer · 2024-09-20T07:55:11Z

It seems like the service string for nm-applet is :1.81 which is shorter than the 6 characters, expected by

eww/crates/notifier_host/src/item.rs

Line 64 in 8661abf

(service[0..6].to_owned(), names::ITEM_OBJECT.to_owned())

I do not know the specifics of dbus / sni, but something about the service just being a few numbers just feels off, isn't it supposed to have a suffix, like described in the comment above the fn in question?

w-lfchen · 2024-09-20T08:29:39Z

that's weird, i can't seem to reproduce this.
which nixpkgs commit are you on?

MonaMayrhofer · 2024-09-20T08:30:26Z

It looks like nm-applet is not providing any of the kde StatusNotifierItem dbus entries, but instead providing the ones from ayatana https://ayatanaindicators.github.io/

-> busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems
as 1 ":1.89"

-> busctl --user tree :1.89
└─ /org
  ├─ /org/ayatana
  │ └─ /org/ayatana/NotificationItem
  │   └─ /org/ayatana/NotificationItem/nm_applet
  │     └─ /org/ayatana/NotificationItem/nm_applet/Menu
  └─ /org/freedesktop
    └─ /org/freedesktop/network_manager_applet

Same thing for udiskie

busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems
as 1 ":1.108"

busctl --user tree :1.108
└─ /org
  └─ /org/ayatana
    └─ /org/ayatana/NotificationItem
      └─ /org/ayatana/NotificationItem/udiskie
        └─ /org/ayatana/NotificationItem/udiskie/Menu

MonaMayrhofer · 2024-09-20T08:32:52Z

Im on:

    "nixpkgs": {
      "locked": {
        "lastModified": 1722221733,
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "12bf09802d77264e441f48e25459c10c93eada2e",
        "type": "github"
      },
      "original": {
        "id": "nixpkgs",
        "ref": "nixos-24.05",
        "type": "indirect"
      }
    },

MonaMayrhofer · 2024-09-20T08:38:35Z

Oh wait, i seem to have mixed things up... udiskie does provide the org.kde.StatusNotifierItem interface - its just under a different path than what eww seems to expect.

-> busctl --user introspect :1.108 /org/ayatana/NotificationItem/udiskie
NAME                                TYPE      SIGNATURE RESULT/VALUE                             FLAGS
org.freedesktop.DBus.Introspectable interface -         -                                        -
.Introspect                         method    -         s                                        -
org.freedesktop.DBus.Peer           interface -         -                                        -
.GetMachineId                       method    -         s                                        -
.Ping                               method    -         -                                        -
org.freedesktop.DBus.Properties     interface -         -                                        -
.Get                                method    ss        v                                        -
.GetAll                             method    s         a{sv}                                    -
.Set                                method    ssv       -                                        -
.PropertiesChanged                  signal    sa{sv}as  -                                        -
org.kde.StatusNotifierItem          interface -         -                                        -
.Scroll                             method    is        -                                        -
.SecondaryActivate                  method    ii        -                                        -
.XAyatanaSecondaryActivate          method    u         -                                        -
.AttentionAccessibleDesc            property  s         ""                                       emits-change
.AttentionIconName                  property  s         ""                                       emits-change
.Category                           property  s         "Hardware"                               emits-change
.IconAccessibleDesc                 property  s         ""                                       emits-change
.IconName                           property  s         "drive-removable-media"                  emits-change
.IconThemePath                      property  s         ""                                       emits-change
.Id                                 property  s         "udiskie"                                emits-change
.Menu                               property  o         "/org/ayatana/NotificationItem/udiskie/… emits-change
.Status                             property  s         "Active"                                 emits-change
.Title                              property  s         "udiskie"                                emits-change
.XAyatanaLabel                      property  s         ""                                       emits-change
.XAyatanaLabelGuide                 property  s         ""                                       emits-change
.XAyatanaOrderingIndex              property  u         0                                        emits-change
.NewAttentionIcon                   signal    -         -                                        -
.NewIcon                            signal    -         -                                        -
.NewIconThemePath                   signal    s         -                                        -
.NewStatus                          signal    s         -                                        -
.NewTitle                           signal    -         -                                        -
.XAyatanaNewLabel                   signal    ss        -                                        -

w-lfchen · 2024-09-20T08:41:13Z

i'm still having issues reproducing this, sorry :/

using nix run github:nixos/nixpkgs/12bf09802d77264e441f48e25459c10c93eada2e#networkmanagerapplet doesn't yield any issues

MonaMayrhofer · 2024-09-20T08:45:54Z

Running that, does no longer lead to a panic for me (however thats only because the nm-applet service is now :1.123 with 3 digits and no longer something with only 2 digits (But thats only because that number seems to continually increase).

However it still doesn't work:

 2024-09-20T08:43:18.392Z WARN  eww::widgets::systray > failed to set menu: org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/StatusNotifierItem”
 2024-09-20T08:43:18.392Z ERROR eww::widgets::systray > error for systray item :1.123: org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/StatusNotifierItem”

Listing the objects of :1.123 still shows there's nothing at /StatusNotifierItem, like eww expects.

-> busctl --user tree :1.123                                            
└─ /org
  ├─ /org/ayatana
  │ └─ /org/ayatana/NotificationItem
  │   └─ /org/ayatana/NotificationItem/nm_applet
  │     └─ /org/ayatana/NotificationItem/nm_applet/Menu
  └─ /org/freedesktop
    └─ /org/freedesktop/network_manager_applet

MonaMayrhofer · 2024-09-20T08:49:47Z

Can you run busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems?

I am curious if your services are also registered at the weird number or if yours actually have a path like line 62 seems to expect:

eww/crates/notifier_host/src/item.rs

Lines 56 to 73 in 8661abf

    
               pub async fn from_address(con: &zbus::Connection, service: &str) -> zbus::Result<Self> { 
        
                   let (addr, path) = { 
        
                       // Based on <https://github.com/oknozor/stray/blob/main/stray/src/notifier_watcher/notifier_address.rs> 
        
                       // 
        
                       // TODO is the service name format actually documented anywhere? 
        
                       if let Some((addr, path)) = service.split_once('/') { 
        
                           (addr.to_owned(), format!("/{}", path)) 
        
                       } else if service.starts_with(':') { 
        
                           (service[0..6].to_owned(), names::ITEM_OBJECT.to_owned()) 
        
                       } else { 
        
                           return Err(zbus::Error::Address(service.to_owned())); 
        
                       } 
        
                   }; 
        
                   let sni = proxy::StatusNotifierItemProxy::builder(con).destination(addr)?.path(path)?.build().await?; 
        
                   Ok(Self { sni, gtk_menu: None }) 
        
               }

w-lfchen · 2024-09-20T08:51:45Z

$ busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems
as 2 ":1.28/org/ayatana/NotificationItem/spotify_client" ":1.13589/org/ayatana/NotificationItem/nm_applet"

MonaMayrhofer · 2024-09-20T08:53:08Z

Yea, thats the problem, for some reason on my system they aren't registering with the object path, just the service, so i fall into line 64, and yours is in line 62

-> busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems
as 1 ":1.123"

w-lfchen · 2024-09-20T08:54:23Z

that seems more like a dbus issue to me though or am i reading this wrong
~~are there any objects registered under that destination?~~
i'm too dumb to read logs my bad
busctl --user tree :1.13589 gives me the same output as yours here

MonaMayrhofer · 2024-09-20T09:01:36Z

Yup, it definitely is an issue with my dbus setup that nm_applet doesn't register the correct object path into the StatusNotifierWatcher.

However it seems like line 64 is supposed to catch this issue and panics for short service names.

There are no objects registered at /StatusNotifierItem, just the ayatana ones at /org/ayatana/NotifictaionItem/nm_applet, like on your system.

If i change line 64 to temporarily hardcode the correct path, so:

                (service[0..(6.min(service.len()))].to_owned(), "/org/ayatana/NotificationItem/nm_applet".into())

it works like a charm....

w-lfchen · 2024-09-20T09:11:48Z

is the [0..(6.min(service.len()))] even needed? it seems useless to me at this point, i'd try simply removing it
i think what should be evaluated is how stray handles this, as the logic seems to be strongly inspired from there

i currently don't really have the time to work on this myself, but feel free to open a pr, i'll do my best to test and review it if you do!
that pr could probably also seek to address #1180, these issues might be related in some way

MonaMayrhofer · 2024-09-20T09:21:01Z

Its very strange - if i monitor the session dbus traffic with bustle or dbus-monitor --session i can see the Message where nm_applet registers itself

method call time=1726823244.902165 sender=:1.150 -> destination=:1.5 serial=25 path=/StatusNotifierWatcher; interface=org.kde.StatusNotifierWatcher; member=RegisterStatusNotifierItem
   string "/org/ayatana/NotificationItem/nm_applet"

and there it includes the correct object path.

You are right the [0..(6.min(service.len()))] should probably be replaced with just service - i wonder what the reason for that slicing was in the first place.

Sure I'll look into it more and PR any things that can actually be resolved within eww, and are not just a misconfiguration on my part.

One thing that could be the culprit is that I am using the status-notifier-watcher service from home-manager to provide the org.kde.StatusNotifierWatcher service which uses haskellPackages.status-notifier-item v0.3.1.0

w-lfchen · 2024-09-20T09:28:00Z

i have not changed anything from the default implementation for status-notifier-watcher, didn't even know there is a hm option for that ^^'
so that might be worth testing

MonaMayrhofer · 2024-09-20T09:32:14Z

Yes!
That was the problem.
That has been a remnant of my taffybar times, I did not realise eww comes with its own ord.kde.StatusNotifierWaatcher service.

Now that i know it, it seems quite obvious.

So it was entirely my fault.

I wonder, however, if we should change up line 64 anyways, cause the slicing is definitely broken as it assumes service names that are exactly 6 chars long, and also as far as I understood it, the object will never be at the path that names::ITEM_OBJECT.to_owned() expects...
But tbh the entire branch kinda seems like a band-aid for some specific application that does werid stuff with the dbus, so I am reluctant to really change it up without knowing why it exists.
Maybe we should at least emit a warning that puts people onto the right track...

w-lfchen · 2024-09-20T13:02:15Z

a warning about falling back to a default attempt to address the object seems reasonable

i think it'd be best to investigate #1180 first tho

MonaMayrhofer · 2024-09-20T13:49:27Z

Then it's probably best to close this issue, and continue all further investigation over there.

Kage-Yami · 2024-11-17T04:37:27Z

So I've just started exploring this because I was getting the panic on my Ultramarine Linux 40 (i.e. Fedora-based) system, running Budgie Desktop (i.e. X11, in case that makes a difference for this)

Not currently on that exact system, but last night when I was, with:

busctl --user \
  get-property org.kde.StatusNotifierWatcher \
  /StatusNotifierWatcher \
  org.kde.StatusNotifierWatcher \
  RegisteredStatusNotifierItems

... I was getting two path-less results as described in this thread (one was for nm-applet, the other for Ulauncher); nm-applet had only a 2-digit ID (i.e. 5-length string).

A quick hack later to remove the [0..6] slicing, and both items failed on a later step; don't remember the exact message, but it was something to do with not being able to find the path.

However, running that command on the system I'm currently on (Fedora 40 with KDE, Wayland), I note that there are items that have the "default" /StatusNotifierItem path, some alongside a 2-digit ID and some alongside a non-numerical ID (newlines inserted to reduce horizontal scrolling pain):

as 9
":1.48/StatusNotifierItem"
":1.61/StatusNotifierItem"
":1.63/org/ayatana/NotificationItem/ulauncher"
":1.71/org/ayatana/NotificationItem/tray_id"
":1.75/StatusNotifierItem"
"com.jetbrains.toolbox/StatusNotifierItem"
":1.76/org/ayatana/NotificationItem/9fS_9JCsD7"
":1.96/StatusNotifierItem"
":1.88/org/ayatana/NotificationItem/steam"

For reference, results of busctl --user tree for ambiguous items above (not that they're all necessarily any more helpful)...

:1.48:

├─ /MenuBar
└─ /StatusNotifierItem

:1.61:

├─ /MenuBar
└─ /StatusNotifierItem

:1.71:

─ /org
 └─ /org/ayatana
   └─ /org/ayatana/NotificationItem
     └─ /org/ayatana/NotificationItem/tray_id
       └─ /org/ayatana/NotificationItem/tray_id/Menu

:1.75:

├─ /StatusNotifierItem
└─ /com
  └─ /com/canonical
    └─ /com/canonical/dbusmenu

:1.76:

└─ /org
  ├─ /org/ayatana
  │ └─ /org/ayatana/NotificationItem
  │   └─ /org/ayatana/NotificationItem/9fS_9JCsD7
  │     └─ /org/ayatana/NotificationItem/9fS_9JCsD7/Menu
  ├─ /org/gtk
  │ └─ /org/gtk/Profiler
  └─ /org/localsend
    └─ /org/localsend/localsend_app
      └─ /org/localsend/localsend_app/window
        └─ /org/localsend/localsend_app/window/1

:1.96:

├─ /StatusNotifierItem
└─ /com
  └─ /com/canonical
    └─ /com/canonical/dbusmenu

(I've not run Eww on this Fedora 40 KDE system, as my intent with Eww is to be able to have a secondary-monitor taskbar on a Budgie system, which does not natively support such a thing, thus letting me reinstall my Fedora 40 KDE [on a two-monitor system] to match the Ultramarine one [which is only single-monitor, but works for experimentation].)

So it seems, depending on environment, at least all of the following permutations are possible (based on observations in this thread, presumably other permutations are also possible):

:<number>.<number>
- may panic due to slicing, but errors regardless because "no path" does not equal "default path"
:<number>.<number>/StatusNotifierItem
- shouldn't be any problems, because follows normal path-based code branch
:<number>.<number>/<string-path>
- shouldn't be any problems, because follows normal path-based code branch
<namespace-string>/StatusNotifierItem
- shouldn't be any problems, because follows normal path-based code branch

I'm not sure at this stage what status-notifier-watcher or home-manager are all about at this time (not yet explored those), but my main take-away is that the failure case is not just a result of "esoteric" environments, but also a result of (what I can only assume are) pretty stock/ordinary DE installations (e.g. Budgie Desktop).

So that probably warrants re-opening this? (Although the issue as described by the title is only 1 of 2 problems...)

I'm going to be exploring this some more, although this is all very new to me (outside of some raw Rust hobby-experience), so can't say whether I'd be able to come up with any more information or ideas...

Kage-Yami · 2024-11-17T12:07:02Z

So I've been able to resolve the issue with these changes: master...Kage-Yami:eww:fix/pathless-systray-items

Basically, it uses DBus interface introspection at a fixed /org/ayatana/NotificationItem path on the "misbehaving" addresses, parses out the resulting XML, and grabs the first child node, assuming that is the correct path for the StatusNotifierItem object we want.

I see a few potential issues (even if only from an "appetite" perspective) with it before it could be merged in (but happy to create a pull request so it can be iterated on):

Introduces a new dependency on quick-xml (and makes serde no longer a transient-only dependency)
- We'll need something to parse the XML, because that's what introspection spits out.
Doesn't validate (e.g. via more introspection) that the result actually implements StatusNotifierItem
Assumes that /org/ayatana/NotificationItem is always the correct parent path to the StatusNotifierItem object
- Are there other "fallback" paths we should check?
- Or should we crawl the entire tree from / looking for objects that implement StatusNotifierItem and take e.g. the first found?
Wrapping of quick-xml errors in zbus errors will break when the zbus 4.x -> 5.x can of worms is opened again
- zbus 5.x removes ::Error::QuickXml (and the quick-xml feature); could probably use the generic ::Error::Failure instead (even before the version bump)?

w-lfchen · 2024-11-17T13:43:07Z

feel free to open a pr!
i'll see whether i can help out, but i'm rather busy these days so please don't expect much.

i don't think it's a good idea to rely on outdated features though, so maybe we should look into different ways to solve this issue (ideally migrating to zbus 5.1.1 while doing so)

Kage-Yami · 2024-11-18T11:56:49Z

PR created: #1230

Ended up taking the time to crawl the tree to find the first org.kde.StatusNotifierItem, instead of just assuming it was directly under /org/ayatana/NotificationItem.

Also scrapped the wrapping of quick-xml errors in xbus::Error::QuickXml, so that should no longer cause us any problems when it comes to zbus upgrade time (which I believe should be done separately, rather than "overload" this change).

MonaMayrhofer added the bug Something isn't working label Sep 20, 2024

w-lfchen mentioned this issue Sep 20, 2024

[BUG] Systray widget doesn't draw tray icon of xfce4-power-manager #1180

Closed

3 tasks

MonaMayrhofer closed this as completed Sep 20, 2024

netboy3 mentioned this issue Sep 20, 2024

[BUG] Systray doesn't update icons properly #1188

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUG] Panic with notifier_host #1202

[BUG] Panic with notifier_host #1202

MonaMayrhofer commented Sep 20, 2024 •

edited

Loading

MonaMayrhofer commented Sep 20, 2024 •

edited

Loading

w-lfchen commented Sep 20, 2024

MonaMayrhofer commented Sep 20, 2024

MonaMayrhofer commented Sep 20, 2024

MonaMayrhofer commented Sep 20, 2024

w-lfchen commented Sep 20, 2024 •

edited

Loading

MonaMayrhofer commented Sep 20, 2024 •

edited

Loading

MonaMayrhofer commented Sep 20, 2024

w-lfchen commented Sep 20, 2024

MonaMayrhofer commented Sep 20, 2024

w-lfchen commented Sep 20, 2024 •

edited

Loading

MonaMayrhofer commented Sep 20, 2024

w-lfchen commented Sep 20, 2024 •

edited

Loading

MonaMayrhofer commented Sep 20, 2024

w-lfchen commented Sep 20, 2024 •

edited

Loading

MonaMayrhofer commented Sep 20, 2024

w-lfchen commented Sep 20, 2024

MonaMayrhofer commented Sep 20, 2024

Kage-Yami commented Nov 17, 2024

Kage-Yami commented Nov 17, 2024 •

edited

Loading

w-lfchen commented Nov 17, 2024

Kage-Yami commented Nov 18, 2024

[BUG] Panic with notifier_host #1202

[BUG] Panic with notifier_host #1202

Comments

MonaMayrhofer commented Sep 20, 2024 • edited Loading

Checklist before submitting an issue

Description of the bug

Reproducing the issue

Additional context

MonaMayrhofer commented Sep 20, 2024 • edited Loading

w-lfchen commented Sep 20, 2024

MonaMayrhofer commented Sep 20, 2024

MonaMayrhofer commented Sep 20, 2024

MonaMayrhofer commented Sep 20, 2024

w-lfchen commented Sep 20, 2024 • edited Loading

MonaMayrhofer commented Sep 20, 2024 • edited Loading

MonaMayrhofer commented Sep 20, 2024

w-lfchen commented Sep 20, 2024

MonaMayrhofer commented Sep 20, 2024

w-lfchen commented Sep 20, 2024 • edited Loading

MonaMayrhofer commented Sep 20, 2024

w-lfchen commented Sep 20, 2024 • edited Loading

MonaMayrhofer commented Sep 20, 2024

w-lfchen commented Sep 20, 2024 • edited Loading

MonaMayrhofer commented Sep 20, 2024

w-lfchen commented Sep 20, 2024

MonaMayrhofer commented Sep 20, 2024

Kage-Yami commented Nov 17, 2024

Kage-Yami commented Nov 17, 2024 • edited Loading

w-lfchen commented Nov 17, 2024

Kage-Yami commented Nov 18, 2024

MonaMayrhofer commented Sep 20, 2024 •

edited

Loading

MonaMayrhofer commented Sep 20, 2024 •

edited

Loading

w-lfchen commented Sep 20, 2024 •

edited

Loading

MonaMayrhofer commented Sep 20, 2024 •

edited

Loading

w-lfchen commented Sep 20, 2024 •

edited

Loading

w-lfchen commented Sep 20, 2024 •

edited

Loading

w-lfchen commented Sep 20, 2024 •

edited

Loading

Kage-Yami commented Nov 17, 2024 •

edited

Loading