nsIObserver Topics
You can register as an observer of many different events. To handle these events, you object must implement the nsIObsever interface. The common way to registry an nsIObserver object is using the nsIObserverService interface.These are the public events outlined below.
XPCOM Topics
| Topic Name |
Description |
How To
Register |
| xpcom-startup |
This notificaiton is sent out
when XPCOM in initally started up. |
You can register for this event
either by using the nsIObserver Service or by adding a category
entry
under the category of the topic name. The category entry and
value must be the contract id associcated with the object to be
notified. |
| xpcom-shutdown |
This notification is sent out
when XPCOM is shutting down. It allows components to
finalize. XPCOM services at that point are no longer available |
You can register for this event either by using the nsIObserver Service or by adding a category entry under the category of the topic name. The category entry and value must be the contract id associcated with the object to be notified. |
| xpcom-autoregistration (start
and end) |
This notification sends out two
topics. When XPCOM beings to registering components in what is
know as auto-registration, a topic with the name of "start" will be
fired. Then when XPCOM completes its auto-registration, a topic
with the name of "stop" will be fired. |
You can register for this event
by using the nsIObserver Service. |
| memory-pressure | This notification is sent when
the available memory passes some threashold. Clients are expected
to release any nonessential resources. The data parameter will
include information as to why the notification occured. Known
reasons are "low-memory", "alloc-failure", and "heap-minimize". |
You can register for this event by using the nsIObserver Service. |
Profile Topics
See nsIProfileChangeStatus.idl for more information. Note that this inteface isn't frozen at the moment.| Topic Name |
Description |
How To
Register |
| profile-approve-change |
Called before a profile change is attempted. Typically, the application level observer will ask the user if he/she wants to stop all network activity, close all open windows, etc. If the user says NO, the observer should call the subject's vetoChange(). If any observer does this, the profile will not be changed. | You can register for this event by using the nsIObserver Service. |
| profile-change-teardown |
All async activity must be
stopped in this phase. Typically, the application level observer will
close all open windows. This is the last phase in which the subject's
vetoChange() method may still be called. The next notification will be
either profile-change-teardown-veto or profile-before-change. |
|
| profile-change-teardown-veto |
This notification will only be
sent, if the profile change was vetoed during the
profile-change-teardown phase. This allows components to bring back
required resources, that were tore down on profile-change-teardown. |
|
| profile-before-change | Called before the profile has
changed. Use this notification to prepare for the profile going away.
If a component is holding any state which needs to be flushed to a
profile-relative location, it should be done here. |
|
| profile-do-change |
Called after the profile has
changed. Do the work to respond to having a new profile. Any change
which affects others must be done in this phase. |
|
| profile-after-change |
Called after the profile has
changed. Use this notification to make changes that are dependent on
what some other listener did during its profile-do-change. For example,
to respond to new preferences. |
|
| profile-initial-state |
Called after all phases of a
change have completed. Typically in this phase, an application level
observer will open a new window. |
Notes:
Contexts for profile changes. These are passed as the someData param to the observer's Observe() method."startup"
Going from no profile to a profile. The following topics happen in this context:
profile-do-change
profile-after-change
"shutdown-persist"
The user is logging out and whatever data the observer stores
for the current profile should be released from memory and
saved to disk.
"shutdown-cleanse"
The user is logging out and whatever data the observer stores
for the current profile should be released from memory and
deleted from disk.
The following topics happen in both shutdown contexts:
profile-approve-change
profile-change-teardown
profile-before-change
"switch"
Going from one profile to another.
All of the above topics happen in a profile switch.
Single Profile
Even with single-profile build, a subset of these notifications are sent out.On startup, in a single-profile build, "profile-do-change" and
"profile-after-change" are sent out when the embedding app calls
nsProfileDirectoryServiceProvider::SetProfileDir().
On shutdown, when the embedding app calls nsProfileDirectoryServiceProvider::Shutdown(),
"profile-before-change" is sent out. This is to allow components which
need to initialize/cleanup to be able to work properly whether
single-profile or not.