511037 - Maemo/OSSO idle service does not work per spec

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Doug Turner (:dougt)]

the Maemo/OSSO idle service currently returns the time that the "device has been idle".  However, the devices we have (n810's) currently report that the device is idle at the same time the screen goes dark -- a few minutes after of idle time.

I think as a first past we should make the Maemo idle service behave similar to what we do on WinCE -- and return the time since the last UI event.  This has a draw back in that we will report that we are "idle" when we are placed into the background, but the user is actively using other applications.

A second order pass might be to ensure that if we are in the back ground, we fall back to using the existing implementation.  For example, while in the background, only report idle when the device reports that we are idle.

Comment 1

[Doug Turner (:dougt)]

Attachment: patch v.1

Comment 2

[Doug Turner (:dougt)]

Comment on attachment 394995 [details] [diff] [review]
patch v.1

we can also remove the OSSO files too.

Comment 3

[Stuart Parmenter]

dougt: rather than using PR_IntervalNow can we just use PR_Now(), which gives back microseconds?

Comment 4

[Doug Turner (:dougt)]

yes, we could, but if the user changes the system clock, mIdle will report the wrong thing.  From the docs of PR_Now:

You cannot assume that the values returned by PR_Now() are monotonically increasing because the system clock of the computer may be reset.

Comment 5

[Doug Turner (:dougt)]

Attachment: ignore

Comment 6

[Doug Turner (:dougt)]

ignore that last patch.

Comment 7

[Stuart Parmenter]

wtc, would you use PR_IntervalNow here or PR_Now?

Comment 8

[Wan-Teh Chang]

I'm sorry, I have no clue about the context of your question.
PR_IntervalNow's limitation is that the 32-bit timestamp it
returns may wrap around in 12 hours, so your calls to
PR_IntervalNow must not be more than 6 hours apart:
https://developer.mozilla.org/en/PRIntervalTime

PR_IntervalNow is specified to be monotonically increasing,
although in some platforms the only possible implementation
is based on the system clock of the computer.

Comment 9

[Oleg Romashin (:romaxa)]

Comment on attachment 394995 [details] [diff] [review]
patch v.1

You have introduced new +    gLastInputEventTime variable, which is works only in Gtk case... 
Why we cannot use already existing MouseKeyboard user interaction counter?
http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsEventStateManager.cpp#942

Comment 10

[Doug Turner (:dougt)]

I was following what the windows widget code does:

http://mxr.mozilla.org/mozilla-central/search?string=gLastInputEventTime


Olli, can we use gLastInputEventTime instead?

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

I think using gLastInputEventTime should be ok.
Perhaps user-interaction-(in)active notifications should be removed eventually
once we have idle service working the same/reasonable way on all platforms.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

... that would mean some changes to idle service api.

Comment 13

[Doug Turner (:dougt)]

Well, there is some difference too.  On desktop platforms, "Idle" means when no one is using the computer.  On mobile, "Idle" means when no one is using the browser.  This is partly due to the lack of APIs that tell you when no one is using the machine on mobile (e.g. on linux we use X screen saver, and on windows, the API is just missing).

Maybe on mobile, we can just use the user interaction notification?

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

> Maybe on mobile, we can just use the user interaction notification?
Ah, indeed, because the user-interaction notification is just about
whether or not user uses the browser.

Comment 15

[Doug Turner (:dougt)]

i was looking at creating a nsIdleServiceDefault which would just be an observer of the user-interaction notification.  One problem that I found was that this implementation isn't started until a consumer wants to know the idle time and we may have missed the last notification.

One solution is to startup the default idle service at startup to monitor idle notifications from the event manager.  Another is to expose an API on the event manager.  But both feel no better than what we have with adding a new variable in the window widget code.

Comment 16

[Doug Turner (:dougt)]

http://hg.mozilla.org/mozilla-central/rev/b15e1cf10edb

Comment 17

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/23ede72138f8