search

citp / news-disinformation-study

A research project on how web users consume, are exposed to, and share news online.
8 stars 2 forks source link

Figure out why browser.idle.onStateChanged has delay #3

Closed jonathanmayer closed 4 years ago

jonathanmayer commented 4 years ago

See comments in the PageEvent module. This looks like it might be an issue in Firefox, at least on macOS.

jonathanmayer commented 4 years ago

@akohlbre reports additional unexpected behavior on her Linux install, where Firefox doesn't go idle if she's interacting with another application. We should carefully document how the browser.idle API behaves on major OSes.

jonathanmayer commented 4 years ago

Looked into this more. The idle WebExtensions API is implemented using the existing XPCOM nsIdleService.

https://searchfox.org/mozilla-central/source/toolkit/components/extensions/parent/ext-idle.js

The underlying implementation for nsIdleService has a couple quirks. First, there's a five-second interval for polling idle state.

https://searchfox.org/mozilla-central/source/widget/nsIdleService.cpp#29

Second, the meaning of idle state varies by platform. On some platforms it's a measurement of time since user input to the operating system, on others it's a measurement of time since user input to the browser.

https://searchfox.org/mozilla-central/source/widget/nsIdleService.cpp#292

For purposes of attention tracking in the PageEvents module, both of these caveats should be fine. A polling interval of five seconds is still good enough for user studies, assuming it remains (relatively) short in comparison to the idle timeout. We'll just lose a little precision on timeouts and resuming interaction with the browser. And since we're tracking when the browser loses focus, it doesn't matter if input to other applications is treated as non-idle state; the browser will have lost focus, and we'll catch that with the windows API. I've added explanatory documentation to the PageEvents module.