User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0

Steps to reproduce:

I have enabled automatic scrolling (autoscroll). When reading a long webpage, I middle-click to activate autoscroll, then move the mouse once so that the scrolling speed matches my reading speed and then don't move the mouse anymore.

Actual results:

After a few minutes (depending on the OS setting), my screensaver kicks in and locks the screen.

Expected results:

While autoscroll is active (and I am reading the webpage), the screensaver should be prevented.

It's the basically the same as watching a long video, there the screensaver is correctly prevented.

Note: I am using KDE Neon 5.25, which is based on Ubuntu 20.04.

Note: This is the same request as this 12-year old bug: https://bugzilla.mozilla.org/show_bug.cgi?id=605743
But since it was apparently rejected without being understood completely, and it's already such a long time ago, I decided to open a new issue instead.

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

This comes with two issues:

1. We don't know on widget level if autoscroll is happening.
2. AFAIK autoscroll starts without actual scrolling, i.e the mark is present but page doesn't scroll. So we may prevent screensaver even without scrolling.

Botond, is there any info on widget level that a page is scrolling? Observer or so? think we may prevent screensaver in such case no matter of scroll source.
Thanks.

I don't think we currently have this information available in the parent process, but we could send it there. I have a recollection of us talking about it before, let me see if I can find it.

Ah, it was a conversation over email. Quoting from it:

It's possible, but there is a bit of plumbing involved due to the fact
that decisions about which events trigger scrolling are made in the
GPU process.

The idea would be to forward APZStateChange notifications to the
parent process widget (they are currently sent only to the content
process).

In RemoteContentController::NotifyAPZStateChange(), in addition to
sending the notification to the content process here, we'd want to
send it to the parent process using logic similar to
NotifyPinchGesture (an existing notification that goes to the parent
process widget). In the GPU process case, this involves remoting
the notification through PAPZCTreeManager (so you'd want to add a
new IPC method to PAPZCTreeManager.ipdl). Finally, the notification
will arrive in ChromeProcessController::NotifyAPZStateChange()
where mWidget is now the parent process widget. The cases of interest
to you are aChange == eTransformBegin ("scrolling started") and
aChange == eTransformEnd ("scrolling stopped").

Note, if we instead wanted to detect whether just autoscroll specifically is happening, that information is already available in the parent process since autoscroll is coordinated from there (e.g. we could send observer notifications from startScroll and stopScroll).

(In reply to Martin Stránský [:stransky] (ni? me) from comment #4)

2. AFAIK autoscroll starts without actual scrolling, i.e the mark is present but page doesn't scroll. So we may prevent screensaver even without scrolling.

I wouldn't worry too much about this edge case. I'm pretty sure that, even with the approach from comment 7, APZ would report that we are "scrolling" in this situation (because APZ will be in the AUTOSCROLL state which it considers a "transforming" state).

Depends on D162977

Depends on D162978

https://hg.mozilla.org/mozilla-central/rev/cd03be9e1602
https://hg.mozilla.org/mozilla-central/rev/a671af6f0028

Thanks to everyone involved fixing this! I'll give it a try once Firefox 109 is in the stable release channel.

I managed to reprodce this issue on Firefox 108.0.1(build ID: 20221215175817) on Ubuntu 22.
Verified as fixed on Firefox 109.0b6(build ID: 20221222190305) and Nightly 110.0a1(build ID: 20221227093156) on Ubuntu 22.