[Bug 2047262]

[Mbarriolinares]

After many hours debugging, finally, a fix.

```
--- a/widget/gtk/WakeLockListener.cpp
+++ a/widget/gtk/WakeLockListener.cpp
@@ -380,11 +380,14 @@
                     },
                     [s = RefPtr{this}, this,
                      aMethod](GUniquePtr<GError>&& aError) {
+                      // We may get a broken reply if the peer DBus service was
+                      // restarted. In such case the service is not inhibited
+                      // anymore so consider this as success.
                       WAKE_LOCK_LOG(
                           "WakeLockTopic::DBusUninhibitFailed() %s call failed "
                           ": %s\n",
                           aMethod, aError->message);
-                      DBusUninhibitFailed();
+                      DBusUninhibitSucceeded();
                     });
           },
           [self = RefPtr{this}, this](GUniquePtr<GError>&& aError) {
@@ -527,7 +530,10 @@
                           "removed\n");
                     },
                     [s = RefPtr{this}, this](GUniquePtr<GError>&& aError) {
-                      DBusUninhibitFailed();
+                      // We may get a broken reply if the peer DBus service was
+                      // restarted. In such case the service is not inhibited
+                      // anymore so consider this as success.
+                      DBusUninhibitSucceeded();
                       WAKE_LOCK_LOG(
                           "WakeLockTopic::UninhibitFreeDesktopPortal() "
                           "Removing inhibit failed: %s\n",
```

So Firefox attempts to uninhibit, the DBus call fails due to the invalid token, and the WakeLockTopic class incorrectly remains in the Inhibited state, preventing further inhibition attempts.
My patch addresses this by modifying the error handling in DBusUninhibitScreensaver and UninhibitFreeDesktopPortal. Instead of calling DBusUninhibitFailed() when a D-Bus error occurs, it calls DBusUninhibitSucceeded(). This is good because a failed uninhibit call due to a restarted DBus service means **the screensaver is already uninhibited** (as the service restart clears all inhibitions). By treating the failure as a success, the WakeLockTopic state correctly transitions to Uninhibited, allowing future inhibition requests to proceed. And voila, I burned all my neurons and my cpu is on fire after many rebuilds of Firefox.

-- 
You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/2047262

Title:
  Firefox stopped inhibiting screensaver on video playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/2047262/+subscriptions