144559 - Timers running during turbo shutdown

Status: RESOLVED WONTFIX

(Core Graveyard :: QuickLaunch (AKA turbo mode), defect)

Description

[Stephen P. Morse]

There are some timers running while we are in turbo shutdown mode.  These might 
or might not be things we want to stop, depending on such things as how often 
the timer fires and how much work it does each time it fires.  See comments in 
bug 143848 for more details

However we should be aware of which timers are still running during shutdown, 
and decide for each one whether it needs to be stopped or not.  As a start at 
determining that, I did a search for all places in which the timers are created 
and will post that list as an attachment.  Then we can look at this list, 
item-by-item, to see if these timers are stopped in turbo mode.

Another approach is to put print statements in the code that is executed each 
time a timer fires.  That way we can see if there are any timers still running 
turbo shutdown.  I tried that and observed at least two separate timers still 
firing.  I'll investigate further to determine which ones they are.  Of course 
that doesn't mean that these are the only ones -- it's just the ones that were 
initialized by the particular paths of the browser that I happened to exercise.

Comment 1

[Stephen P. Morse]

Attachment: list of timers that are created in our sourcecode

Comment 2

[Stephen P. Morse]

It might also be useful to know which of the classes that create timers do not 
handle session-logout notifications.  To determine that, I created a list of 
those places in our codebase in which session-logout observers are created.  
There are relatively few.  I'll attach that list.

Comment 3

[Stephen P. Morse]

Attachment: list of session-logout observers that are created in our sourcecode

Comment 4

[Stephen P. Morse]

My investigation revealed at least the following four timers still going off 
during turbo shutdown are:

   OnBiffTimer in nsMsgBiffManager.cpp (this is the topic of bug 143848)
   DeadConnectionCleanupCB in nsHTTPHandler.cpp
   FireTimer in nsBookmarksService.cpp
   FireTimer in nsInternetSearchService.cpp
   

Comment 5

[Stephen P. Morse]

Here are some numbers on the frequency of the four timers that I've observed 
running during turbo shutdown:

30 sec:   OnBiffTimer in nsMsgBiffManager.cpp
 6 sec:   FireTimer in nsInternetSearchService.cpp
 1.5 sec: DeadConnectionCleanupCB in nsHTTPHandler.cpp
 1.5 sec: FireTimer in nsBookmarksService.cpp

cc'ing the appropriate module owners.

Comment 6

[Darin Fisher]

DeadConnectionCleanupCB is basically a nop after session-logout.  we could
easily kill the timer for this when that notifications is sent.

Comment 7

[Stephen P. Morse]

correction -- I was off by a factor of ten.  The correct timer periods are:

300 sec: OnBiffTimer in nsMsgBiffManager.cpp
 60 sec: FireTimer in nsInternetSearchService.cpp
 15 sec: DeadConnectionCleanupCB in nsHTTPHandler.cpp
 15 sec: FireTimer in nsBookmarksService.cpp

Comment 8

[Stephen P. Morse]

Below is a list of those files that create timers.  I've also included the 
person that I think is the owner of that section of code.

Could each of you please look this over and report back whether
   a) the timer is already cancelled before entering turbo shutdown
   b) it's ok to keep this timer running during turbo shutdown
   c) we need to file a bug to have that timer cancelled

 1 sfraser         /editor/composer/src/nsInterfaceState.cpp
 2 sfraser         /editor/composer/src/nsComposerCommandsUpdater.cpp
 3 hewitt          /extensions/inspector/base/src/inSearchLoop.cpp
 4 bnesse          /extensions/pref/autoconfig/src/nsAutoConfig.cpp
 5 radha           /docshell/base/nsDocShell.cpp
 6 pinkerton       /embedding/browser/webBrowser/nsDocShellTreeOwner.cpp
 7 peterlubczynski /modules/plugin/base/src/nsPluginViewer.cpp
 8 tor             /modules/libpr0n/decoders/mng/imgContainerMNG.cpp
 9 pavlov          /modules/libpr0n/src/imgContainer.cpp
10 rangansen       /security/manager/ssl/src/nsNSSComponent.cpp
11 dougt           /netwerk/protocol/ftp/src/nsFtpProtocolHandler.cpp
12 darin           /netwerk/protocol/http/src/nsHttpHandler.cpp
13 rods            /content/base/src/nsDocumentViewer.cpp
14 cmanske         /content/base/src/nsSelection.cpp
15 pinkerton       /content/events/src/nsEventStateManager.cpp
16 vidur           /content/html/document/src/nsHTMLContentSink.cpp
17 jst             /dom/src/base/nsGlobalWindow.cpp
18 jst             /dom/src/base/nsJSEnvironment.cpp
19 kmcclusk        /layout/base/src/nsCaret.cpp
20 kmcclusk        /layout/html/base/src/nsPresShell.cpp
21 kmcclusk        /layout/html/base/src/nsObjectFrame.cpp
22 kmcclusk        /layout/html/base/src/nsTextFrame.cpp
23 kmcclusk        /layout/html/forms/src/nsListControlFrame.cpp
24 hewitt          /layout/xul/base/src/nsMenuFrame.cpp
25 hewitt          /layout/xul/base/src/nsMenuPopupFrame.cpp
26 hewitt          /layout/xul/base/src/nsXULTooltipListener.cpp
27 hewitt          /layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp
28 hewitt          /layout/xul/base/src/tree/src/nsTreeSelection.cpp
29 hewitt          /layout/xul/base/src/nsListBoxBodyFrame.cpp
30 hewitt          /layout/xul/base/src/nsRepeatService.cpp
31 pavlov          /view/src/nsScrollingView.cpp
32 pavlov          /webshell/tests/viewer/nsThrobber.cpp
33 blizzard        /widget/src/gtk/nsWindow.cpp
34 sfraser         /widget/src/mac/nsSound.cpp
35 pinkerton       /widget/src/cocoa/nsSound.cpp
36 pavlov          /widget/src/windows/nsAppShell.cpp
37 pavlov          /xpfe/appshell/src/nsWebShellWindow.cpp
38 tbogard         /xpfe/browser/src/nsBrowserInstance.cpp
39 rjc             /xpfe/components/bookmarks/src/nsBookmarksService.cpp
40 rjc             /xpfe/components/directory/nsDirectoryViewer.cpp
41 alecf           /xpfe/components/history/src/nsGlobalHistory.cpp
42 rjc             /xpfe/components/search/src/nsInternetSearchService.cpp
43 sgehani         /xpfe/components/updates/src/nsUpdateNotifier.js
44 bienvenu        /mailnews/base/search/src/nsMsgSearchSession.cpp
45 bienvenu        /mailnews/base/src/nsMsgBiffManager.cpp
46 rachum          /mailnews/base/src/nsMessengerWinIntegration.cpp
47 sspitzer        /mailnews/news/src/nsNNTPProtocol.cpp
48 sspitzer        /mailnews/news/src/nsNntpIncomingServer.cpp
49 aaronl          /accessible/src/base/nsRootAccessible.cpp

Comment 9

[Peter Lubczynski]

Plugin timers (nsObjectFrame.cpp and nsPluginViewer.cpp) go away with the
document and plugin so they shouldn't be around during shutdown.

Comment 10

[Alec Flett]

the global history timer is for flushing global history to disk, so the timer
may or may not be pending during shutdown. it is ok to cancel the timer, as long
as global history is written to disk at some point (which I think is done when a
profile shuts down?)

Comment 11

[Mike Pinkerton (not reading bugmail)]

6) embedding only, doesn't affect you
15) mac only, doesn't affect you
35) chimera only, doesn't affect you

Comment 12

[Charles Manske]

I don't know anything about the timer code for this file:
14 cmanske         /content/base/src/nsSelection.cpp
Looks like it's a timer for autoscroll. 
Kin wrote that code.

Comment 13

[David :Bienvenu]

44 /mailnews/base/search/src/nsMsgSearchSession.cpp is only used when doing a
search of local folders, so it wouldn't be active during shutdown.

Comment 14

[kinmoz]

This timer:

14 cmanske         /content/base/src/nsSelection.cpp

is invoked when the user clicks and drags out of the content area, to keep
auto-selection-scrolling going. The timer is killed as soon as the button goes up.

Comment 15

[Rangan Sen]

This timer:
rangansen       /security/manager/ssl/src/nsNSSComponent.cpp
is started when NSS is started up, and stopped at NSS shutdown. During turbo
shutdown, if the tray icon is kept alive, then NSS is still running and so, this
timer should be running too.

Comment 16

[Radha on family leave (not reading bugmail)]

/docshell/base/nsDocShell.cpp

Docshell uses timers only to load and manage refresh urls. Timers are cancelled
when the docshell object is destroyed. There shouldn't be any timers running
after express shutdown is done. 

Comment 17

[Aaron Leventhal]

None of the accessibility timers should be running during shutdown.

Comment 18

[Robert John Churchill]

39 rjc             /xpfe/components/bookmarks/src/nsBookmarksService.cpp
   now ben         This timer is used to implement Bookmark scheduling, i.e.
                   detect when the |URL|'s contents has changed and is
                   cancelled in the Bookmark Service's destructor.

40 rjc             /xpfe/components/directory/nsDirectoryViewer.cpp
   now ???         This timer is used to work around an old issue with incoming
                   FTP data starving the UI during content creation. It
                   Its lifetime should equal that of the FTP data connection.

42 rjc             /xpfe/components/search/src/nsInternetSearchService.cpp
   now sgehani     This timer is used to implement auto-updating search files
                   by checking whether an online version of the file is newer
                   and is cancelled in the search service's destructor.

Comment 19

[Samir Gehani]

> 43 sgehani         /xpfe/components/updates/src/nsUpdateNotifier.js

One-time timer that fires 5 minutes after the first window is opened
(post-profile selection).  Can go off during turbo-shutdown if the latter event
takes place before the one-time timer has had a chance to fire.  

Comment 20

[Brian Nesse (gone)]

> 4 bnesse          /extensions/pref/autoconfig/src/nsAutoConfig.cpp

This timer will only exist when Auto Configuration [netscape.cfg] is being used
(i.e. an enterprise environment). Furthermore it will only be active if the
system administrator has enabled it by using the "autoadmin.refresh_interval"
preference. The purpose of this timer is to insure that global configuration
changes are picked up by the system when it is running, insead of waiting for
the next restart. For this reason, in principal, I believe that it is valid for
this timer to continue running in turbo shutdown mode.

There is, however, a caveat. The function of this timer is to re-download the
autoconfig file from the server. This 1) assumes that necko is running, and 2)
causes network activity. For these reasons it is possible we may not want the
timer running in turbo shutdown mode.

Comment 21

[Brian Nesse (gone)]

As an addendum to the above... This is a repeating timer, the rate determined by
the system administrator. The documentation for "autoadmin.refresh_interval"
strongly recommends that care is excersised when setting this to reduce network
traffic (i.e. use a large value... the preliminary document I have shows 30
minutes as an example.) In the end the interval will be chosen by the administrator.

Comment 22

[Johnny Stenback (:jst)]

None of the timers that I'm aware of in the DOM code are repeating (not on a
lowlevel timer level at least), and only one of them can fire after the last
window is closed. That timer though (used for scheduling GC's), is canceled when
we get a shutdown notification. That's all that's needed from the DOM code, right?

Comment 23

[Stephen P. Morse]

From Blizzard:

None of these timers will happen after the last window has closed. 
There are two timers there, one for drag and drop, which is only running 
during a drag, and one for the IC window which is only around during the 
lifetime of a window.

Comment 24

[David :Bienvenu]

The other timer with my name on it (biff) is the whole reason for this bug, and
is addressed in bug 143848

Comment 25

[Stephen P. Morse]

from darin:

see comment #6.  the nsHttpHandler timer does indeed run continuously while in 
turbo sleep mode, but it does nothing, so it isn't
really anything worth worrying about.  that said, it could be easily stopped 
when sleeping.

Comment 26

[Stephen P. Morse]

from vidur:

The timer in question is only scheduled when a page is loading. There should be 
no pages loading after the last window has closed, so
it should fall into the first category.

Comment 27

[Stuart Parmenter]

all the timers with mine name on them should be fine.

Comment 28

[Stephen P. Morse]

comments from kevin mcclusky (category 1 means not running after last window is 
closed)

-----

1 sfraser         /editor/composer/src/nsInterfaceState.cpp
Looks like it fits into category 1. The timer will be destroyed when the 
document is destroyed so it will not live after the last window
is shutdown.

2 sfraser         /editor/composer/src/nsComposerCommandsUpdater.cpp
Looks like it fits into category 1. The timer will be destroyed when the 
document is destroyed so it will not live after the last window
is shutdown.

19 kmcclusk       /layout/base/src/nsCaret.cpp
mjudge owns the caret code which launches the timer. Glancing at it. It looks 
like this falls into category 1. Timer used only  to blink
the caret and should be destroyed when last window goes away.

20 kmcclusk       /layout/html/base/src/nsPresShell.cpp
hyatt owns the paint suppression code which launches a timer. It looks like this 
falls into category 1. The paint suppression timer will
be destroyed when the window is destroyed.

joki owns the resize event timer. It looks like it falls into category 1. It is 
destroyed when the presshell is destroyed so it should not
exist when the last window is shutdown.

21 kmcclusk       /layout/html/base/src/nsObjectFrame.cpp
peterl owns this code. Looks like the plugin timer is destroyed if the 
ObjectFrame is destroyed so it also fits into category 1. There
shouldn't be any plugin timer if the last window is destroyed. The plugin timer 
is used to give idle time to the plugin.

22 kmcclusk       /layout/html/base/src/nsTextFrame.cpp
Looks like simon owns this. The timer is used to manage blinking text. As far as 
I know blink is not working right now. 
But it looks like it fits into category 1. The blink timer is killed when the 
last textframe with blink turned on is destroyed, so it will be
destroyed when the last window is closed.

23 kmcclusk       /layout/html/forms/src/nsListControlFrame.cpp
rods owns this. Looks like it fits into category1. When the listcontrol frame is 
destroyed the timer is destroyed so it will not live after
the window is destroyed.

Comment 29

[Joe Hewitt (gone)]

24 hewitt          /layout/xul/base/src/nsMenuFrame.cpp
Safe - only active while mousing around inside an open menu popup.
25 hewitt          /layout/xul/base/src/nsMenuPopupFrame.cpp
Safe - only active while holding down a key while navigating menus.
26 hewitt          /layout/xul/base/src/nsXULTooltipListener.cpp
Safe - only active while moving the mouse around a xul document.
27 hewitt          /layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp
Safe - only active during drag operations over a tree for spring loading.
28 hewitt          /layout/xul/base/src/tree/src/nsTreeSelection.cpp
Safe - only active while holding down a key while focused on a tree.
29 hewitt          /layout/xul/base/src/nsListBoxBodyFrame.cpp
Safe - only active while holding down a key while focused on a listbox.
30 hewitt          /layout/xul/base/src/nsRepeatService.cpp
Safe - only active while holding mouse down over scrollbar buttons/track.

Comment 30

[Stephen P. Morse]

Addition comment from hewitt regarding 3
/extensions/inspector/base/src/inSearchLoop.cpp

   That code is in DOM Inspector and it is never used.

Comment 31

[Stephen P. Morse]

Most of the timers are now accounted for.  I just spoke to seth and he is going 
to respond for timers 46, 47, and 48.

I looked at the remaining other outstanding timers and concluded the following:

 8 /modules/libpr0n/decoders/mng/imgContainerMNG.cpp
   timers are for animated images and are cancelled when animation stops
   not active when in turbo mode

11 /netwerk/protocol/ftp/src/nsFtpProtocolHandler.cpp
   used to see if ftp transfer times out
   might fire once after turbo shutdown if ftp transfer is in progress

34 /widget/src/mac/nsSound.cpp
   mac only -- therefore has nothing to do with turbo mode

38 /xpfe/browser/src/nsBrowserInstance.cpp
   handles async page loading
   cancelled when page is finished loading
   not active when in turbo mode

Will summarize all this shortly

Comment 32

[Stephen P. Morse]

I just spoke to Rangan regarding the security timer

   10 rangansen       /security/manager/ssl/src/nsNSSComponent.cpp

See his comment 15.  This is one of the few timers that will keep running in 
turbo mode, so I wanted to understand this better.  Here is what I learned.

The timer doesn't start up until the user either visits an https site or opens 
the pref panel and checks off some security preferences.  Once started, the 
timer continues running even during turbo shutdown.

The purpose of the timer is to do an automatic update of the certificate 
revocation list so that the list can be updated in the background.  The desire 
was to have this background updating continuing to occur, even after the last 
window closes and the browser enters its turbo sleep state.  Of course if turbo 
were not present the timer would stop completely between browser sessions, so 
it's not essential that the timer be kept on during turbo sleep.  But because 
turbo exists, the security people wanted to capitalize on the turbo sleep state 
to continue doing its background auto updates.

Comment 33

[timeless]

given that we have people filing bugs about us acting as a web server when they 
use personal firewalls that record this information, i expect we'll get similar 
bugs from them when we start connecting to web sites when no windows are 
closed.

if we want to do this, we should inform the user once and get their permission.

Comment 34

[Rangan Sen]

cc-ing Stephane

Comment 35

[Peter Trudelle]

It seems like a bad risk/benefit tradeoff to be behaving differently like this
just because turbo happens to be running.  I'd much rather keep these cases as
simple as possible.  If stopping the timer is good enough for usual shutdown,
then it should be good enough for turbo.

Comment 36

[Rangan Sen]

>> when we start connecting to web sites when no windows are closed.

For CRLs, autoupdate happens ONLY for those CRL's which the user has explicitly
enabled for automatic update.

Comment 37

[Stephen P. Morse]

I've just about finished my analysis, so here are the results (modulo items 
46,47, and 48 which I'm waiting to hear from seth about).

Most of the 49 timers are specific to a function and are long since gone by the 
time we get to turbo mode.  Of those that can occur in turbo mode, I've 
classified them as follows:


ONE TIME (or only a few times) AFTER ENTERING TURBO SHUTDOWN
------------------------------------------------------------

13 /content/base/src/nsDocumentViewer.cpp (while printing in progress)
40 /xpfe/components/directory/nsDirectoryViewer.cpp (while ftp in progress)
41 /xpfe/components/history/src/nsGlobalHistory.cpp (while flushing global hist) 
43 /xpfe/components/updates/src/nsUpdateNotifier.js (5 min. after 1st window    
opened)
11 /netwerk/protocol/ftp/src/nsFtpProtocolHandler.cpp (while ftp in progress)


PERIODIC AFTER SHUTDOWN (conditional on certain things happening first)
-----------------------------------------------------------------------

 4 /extensions/pref/autoconfig/src/nsAutoConfig.cpp
   pick up autoconfig changes
   only if system admin has initiatied it
10 /security/manager/ssl/src/nsNSSComponent.cpp
   auto update the certificate revocation list
   only if https occurs or user opens pref panel

PERIODIC AFTER SHUTDOWN (unconditional)
---------------------------------------

12 darin           /netwerk/protocol/http/src/nsHttpHandler.cpp
   runs but doesn't do anything.  could be easily stopped
39 rjc             /xpfe/components/bookmarks/src/nsBookmarksService.cpp
   implements bookmark scheduling
42 rjc             /xpfe/components/search/src/nsInternetSearchService.cpp
   implements auto-updating of search files
45 bienvenu        /mailnews/base/src/nsMsgBiffManager.cpp
   topic of bug 143848

Note that the four unconditional repeating timers are indeed the ones that I 
previously discovered experimentally (see comment 4 and comment 7)

Comment 38

[Stephen P. Morse]

Here's one more wrinkle in the story.  As of yesterday a new turbo model was 
checked into the trunk and will hopefully land on the branch next week.  See bug 
98673 for details).  This results in a full shutdown and process restart when 
the last window closes.  So that changes the way we need to view the above 
timers.

For one thing, the one-time timers will never get a chance to start up and so 
are completely a non-issue (there were virtually a non-issue even with the old 
turbo model since they stopped relatively quickly).  Furthermore, the 
conditional timer 10 starts up only after the user takes certain actions in the 
browser, so it will not have started up yet.  Ignoring the system-admin 
initiated timer (timer 4), that leaves just the four unconditional periodic 
timers to consider.

Of those two of them are initiated late in the browser startup cycle, after the 
leading turbo sleep terminates.  So they are not an issue.  In fact, the only 
timers left that keep going off during the leading turbo sleep are

12 darin           /netwerk/protocol/http/src/nsHttpHandler.cpp
   runs but doesn't do anything.  could be easily stopped
39 rjc             /xpfe/components/bookmarks/src/nsBookmarksService.cpp
   implements bookmark scheduling

Darin has already said that the http timer 12 is a no-op and probably should 
have been turned off before entering turbo mode.  So now I'm making a different 
statement -- it should not be turned on until after exiting the initial turbo 
sleep.  And probably the same applies to the bookmark timer 39.

I'll open separate bug reports to have those two timers started up later in the 
cycle, and keep this bug as a tracking bug on those two.

Comment 39

[Stephen P. Morse]

Let me just clarify the points I made in comment 38 about the new turbo model.  
The new model consists of a turbo sleep state, followed by a normal windows-open 
state followed by process terminate when last window closes.  Immediate upon the 
process termination, a new process is started which goes through the three 
states.

So the only turbo sleep state that we are now concerned about is the one 
preceding the opening of the first window.

Comment 40

[Stephen P. Morse]

I just opened the following two bug reports on the two timers that are running 
in the initial turbo sleep mode.

146553: timer 12 /netwerk/protocol/http/src/nsHttpHandler.cpp
146554: timer 39 /xpfe/components/bookmarks/src/nsBookmarksService.cpp

Comment 41

[Stephen P. Morse]

I just received e-mail from bbaetz confirming what I concluded about 
nsFTPProtocolHandler.cpp in comment 31.  Namely it is a one-time thing.  In 
fact, it's several one-time ticks, one for each cached server.

Comment 42

[(not reading, please use [e-mail] instead)]

47 sspitzer        /mailnews/news/src/nsNNTPProtocol.cpp

this is the timer we use for when updating the subscribe dialog (when getting 
the list of news groups from the server.)  It will not unless you're doing 
that.  so not active when in turbo mode

working on the other 46 and 48 now...

Comment 43

[(not reading, please use [e-mail] instead)]

46 racham          /mailnews/base/src/nsMessengerWinIntegration.cpp

this is the timer that fires to update the registry with the unread count (for 
winxp integration.)  It gets cancelled properly when "exiting" into turbo.
so not active when in turbo mode.

48 sspitzer        /mailnews/news/src/nsNntpIncomingServer.cpp

this is the timer that fires flush the newsrc to disk.  It gets cancelled 
properly when "exiting" into turbo.  so not active when in turbo mode.

Comment 44

[Stephen P. Morse]

reassigning

Comment 45

[Wayne Mery (:wsmwk)]

bug now obsolete, with the passing of "turbo"?

Comment 46

[Matthias Versen [:Matti]]

Quicklaunch/Turbo Mode is no longer supported in Seamonkey 2 and Seamonkey1.X is in the maintenance mode (fixing only security bugs)