Closed Bug 795430 Opened 12 years ago Closed 11 years ago

browser-cleanup-thumbnails timer can fire during startup

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Gavin, Unassigned)

Details

(Whiteboard: [Snappy])

I noticed this in my trace-malloc very-slow-startup debug build. Seems like we should never be doing cleanup on startup.

Also, the registration for browser-cleanup-thumbnails happens very early in startup (before almost anything else visible in the log output) - is it really necessary to initialize PageThumbs that early?
Whiteboard: [Snappy]
The thumbnail code running at startup is:

* The thumbnail storage is migrated if needed. I think we should do this early on startup as there might be a new tab page being restored and we'd want to have thumbnails. This should not occur often and if so, then only after an update where I suppose lots of other migration code run as well.

* A history service observer is registered. This should not impact startup times.

* The expiration timer is registered and this can (theoretically) indeed fire at unfortunate times and we need to fix that.
So I looked into this but couldn't reproduce it. From my understanding of nsUpdateTimerManager.js the minimum wait time after startup before any of the update timers fires is 120 secs. The only way this *could* happen is when we register a timer with an interval < 120 secs but it's in fact a const with a value of 3600 secs.
Hrm, could something have changed since when I filed this? The trace-malloc build that I saw this in did take a long time to start up, but not 3720 seconds :)
It's also possible that there is (or was) some timer weirdness leading to unexpected behavior. I will try to reproduce again.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #3)
> Hrm, could something have changed since when I filed this? The trace-malloc
> build that I saw this in did take a long time to start up, but not 3720
> seconds :)

If we Firefox was closed for more than 3600 secs (time since last thumbnail expiration) and you start it up, it should fire the expiration timer after 120 seconds. So if that's all given (you can also cut off some numbers at the end of the pref to simulate that) and your build takes more then two minutes to start up that could be the cause.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.