[Webkit-unassigned] [Bug 194500] New: [WPE][GTK] Sleep disabler code is not working

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=194500

            Bug ID: 194500
           Summary: [WPE][GTK] Sleep disabler code is not working
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK+
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at igalia.com
                CC: bugs-noreply at webkitgtk.org

Splitting this out of bug #18697, I see I wrote this comment when writing SleepDisablerGlib:

    // We don't support suspend ("System") inhibitors, only idle inhibitors.
    // To get suspend inhibitors, we'd need to use the fancy GNOME
    // SessionManager API, which requires registering as a client application,
    // which is not practical from the web process. Secondly, because the only
    // current use of a suspend inhibitor in WebKit,
    // HTMLMediaElement::shouldDisableSleep, is suspicious. There's really no
    // valid reason for WebKit to ever block suspend, only idle.

There are three things wrong with this comment:

 * Nowadays, GNOME suspends the computer automatically on inactivity, and we actually do want to prevent that.
 * Inhibiting idle does affect the autosuspend countdown. So the current code should prevent automatic suspend, just not manual suspend. (I think I stand by my comment that we do not want to inhibit normal suspend, since that would just be annoying.)
 * I don't know why I thought HTMLMediaElement::shouldDisableSleep was suspicious.

Anyway, I guess the behavior we want is to ignore the Type argument and just always inhibit idle. That is, treat type=System the same way we current treat type=Display. I couldn't decide which to do when I wrote this code, but in retrospect that would have been a better option.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190211/c39831eb/attachment.html>