This looks to be a Firefox bug, likely introduced in version 131. Using dbus-monitor, I captured several occasions where an UnInhibit request was not sent after Inhibit:
It removes the first ocurrence of the element in the array. it should remove all ocurrences.
maybe something like this:
// Iterate through the array backwards and remove all matching pointersfor(ginti=inhibit->priv->array->len-1;i>=0;i--){if(g_strcmp0(((Inhibitor*)g_ptr_array_index(inhibit->priv->array,i))->app_name,inhibitor->app_name)==0){g_ptr_array_remove_index(inhibit->priv->array,i);}}
Removes the pointer at the given index from the pointer array. The following elements are moved down one place. If array has a non-NULL GDestroyNotify function it is called for the removed element. If so, the return value from this function will potentially point to freed memory (depending on the GDestroyNotify implementation).
No, I don't think so, the inhibitor is unique, as is the connection name. When the connection is lost, the inhibitor is removed from the array by retrieving it from the connection name: this is correct. If an inhibitor remains when an application crashes, someone who can reproduce the problem should debug it precisely, rather than patching haphazardly.
Any application may crash or die due to multiple reasons.
xfce4-power-manager could at least keep track of the application PID and CMD that send an inhibit request and in the case this combination of PID/CMD no longer exists, the request is invalidated.
Checking this every 60 seconds sounds like a simple enough solution.
Hi, I got the same "firefox is currently inhibiting power management" message on Xubuntu 24.10.
Originally I had problem with system suspending. Fixed it and two days later got this. Looks like it's Firefox problem. However it stop by system to suspend again (which drains battery a lot and closing a lid). I opened Mozilla bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1928198 Vote if you are also affected.
Another option would be blacklisting Firefox, that is ignore its PM inhibit requests until we know this issue has been fixed in Firefox. But I can see in https://bugzilla.mozilla.org/show_bug.cgi?id=1862159 they are actively working on it, albeit with mixed success.
@birdie that is a good point but in case of Firefox this is not triggered by a crash. Report say it can be replicated by closing a window playing media.
I probably won't be able to help here myself, as (on desktop) I cannot reproduce all the issues mentioned here.
I've unlocked your account, so you can now create a merge request.
I still haven't had time to really look into this, but I can already tell you that it's wrong: the purpose of xfpm_inhibit_free_inhibitor is to free an inhibitor, not to do anything else. If a loop is to be made, it should be made externally and call xfpm_inhibit_free_inhibitor.
And I'm inclined to believe that it should only take place when the name is lost on dbus. Because here, if an application wants to remove only one of its inhibitors (since they are also associated with a single token), you remove them all. Maybe this doesn't happen very often in practice, but that's how I think this thing is supposed to work.
* : What we do if the application inhibiting the power manager crahes and didn't send us the cookie back, the power manager will stay in inhibit state until a session restart, should we monitor the DBusConnection opened by that application?
Well, we monitor the connection apparently, but you're probably right that we don't remove everything we should in this case. Could you open a merge request please, there are CI checks there, for coding style in particular.
I'm sorry to reopen this issue, but I've discovered that stressing the inhibitors still leaves lingering inhibitors in place, even after the app is closed.
Below is a Python script that randomly creates and destroys inhibitors in two threads. After running it for a few seconds and killing the process, some inhibitors remain and cannot be removed.
Is there any chance that this will correspond to a situation encountered in practice? In any case, I think your patch above does indeed fix the problem encountered with firefox in at least most cases, right?
So I think we could leave this issue alone, and open another dedicated to improving this inhibitor removal. Another fix for this is obviously welcome.
My patch fixed the problem in most cases, yes. Firefox dbus handling is weird though.
In my heavy daily Firefox use, I hit this bug about once a week. That is why I made the script above to stress xfce and see what was happening. (maybe somebody can debug it)
"I'd rather my monitor turn off unnecessarily than stay on forever."