Hi Florian, do you know if that this issue is still present or if APIs have been changed so that we could better detect those situations? I wonder how much it could affect the power performance.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #2)

Hi Florian, do you know if that this issue is still present or if APIs have been changed so that we could better detect those situations?

I don't know about this specific situation of desktop notifications resetting the idle time, but we have an issue that definitely exists where interacting with any other application resets the idle time in Firefox.

I wonder how much it could affect the power performance.

I just put for review a patch in bug 1768920 that should change the behavior to improve power performance of the user idle service. If the patch goes through, this bug should no longer exist, as we will only send a "back" notification if Firefox receives user events.

Actually, looking at a long profile of Firefox sitting there doing nothing, we reset the idle service about once per hour, when receiving a WM_MOUSEMOVE message from Windows: https://share.firefox.dev/3kxptEd

Interestingly, the mouse moves are all for the same position on the screen, and our event handling code has a test to avoid triggering a DOM event in that case, but still calls UserActivity(): https://searchfox.org/mozilla-central/rev/3ede9deb876ad5d6389cb51b371d4a4c8d788deb/widget/windows/nsWindow.cpp#4428,4440-4443

https://hg.mozilla.org/mozilla-central/rev/4751a60ba983

I profiled a nightly with the fix last night: https://share.firefox.dev/3KK5NHY
It didn't receive a hourly WM_MOUSEMOVE message as I saw in the profile in comment 4, but there was still one WM_MOUSEMOVE message during the night, and the profile confirms it didn't reset the user idle time.