518802 - nsNavHistory:: repeating history expire timer breaks power management

Status: RESOLVED FIXED

(Toolkit :: Places, defect)

Description

[Oleg Romashin (:romaxa)]

Attachment: Proposed solution for places expiration timer

Current nsNavHistory implementation use TYPE_REPEATING_SLACK timer which is waking up every 5 minutes.

I think when system is in idle state, we should switch it to 1 day timer or disable timer at all.

Comment 1

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

This is only used when preferences change and we must catch up with new values for privacy reasons.

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

also i'm not sure that moving more stuff to daily idle is really good for mobile, is idle a common state for these devices? for example i usually navigate to a website, find information i need and close the browser.
Do we know if idle is something that really happens on these kind of devices, or are users going to close the app as soon as they have completed their current search task?

We have bunch of stuff in idle, and looking at my mobile usage i think all of that won't ever run for certain users, 5 or 10 minutes of idle could never happen there (leaving the phone/moiledev 10 minutes with the browser open without doing anything).

Comment 3

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

that said, we are going to rewrite expiration in the next weeks, so if you have suggestions and statistics about how mobile hits idle, and which strategies would e good on those devices, we are largely interested in that.

Comment 4

[Oleg Romashin (:romaxa)]

I don't have any statistics, I'm just proposing to suspend all repeating timers during system-idle-time.

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

yes, i'm saying that this repeating timer exists only when history prefs change, so this specific problem is a minor thing, won't hurt any common use.

Comment 6

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Async expiration should have solved this.