Tue, 06 Jan 2015 21:39:09 +0100
Conditionally force memory storage according to privacy.thirdparty.isolate;
This solves Tor bug #9701, complying with disk avoidance documented in
https://www.torproject.org/projects/torbrowser/design/#disk-avoidance.
michael@0 | 1 | This Source Code Form is subject to the terms of the Mozilla Public |
michael@0 | 2 | License, v. 2.0. If a copy of the MPL was not distributed with this |
michael@0 | 3 | file, You can obtain one at http://mozilla.org/MPL/2.0/. |
michael@0 | 4 | |
michael@0 | 5 | nsIObserver topics for profile changing. Profile changing happens in phases |
michael@0 | 6 | in the order given below. An observer may register separately for each phase |
michael@0 | 7 | of the process depending on its needs. |
michael@0 | 8 | |
michael@0 | 9 | "profile-change-teardown" |
michael@0 | 10 | All async activity must be stopped in this phase. Typically, |
michael@0 | 11 | the application level observer will close all open windows. |
michael@0 | 12 | This is the last phase in which the subject's vetoChange() |
michael@0 | 13 | method may still be called. |
michael@0 | 14 | The next notification will be either |
michael@0 | 15 | profile-change-teardown-veto or profile-before-change. |
michael@0 | 16 | |
michael@0 | 17 | "profile-before-change" |
michael@0 | 18 | Called before the profile has changed. Use this notification |
michael@0 | 19 | to prepare for the profile going away. If a component is |
michael@0 | 20 | holding any state which needs to be flushed to a profile-relative |
michael@0 | 21 | location, it should be done here. |
michael@0 | 22 | |
michael@0 | 23 | "profile-do-change" |
michael@0 | 24 | Called after the profile has changed. Do the work to |
michael@0 | 25 | respond to having a new profile. Any change which |
michael@0 | 26 | affects others must be done in this phase. |
michael@0 | 27 | |
michael@0 | 28 | "profile-after-change" |
michael@0 | 29 | Called after the profile has changed. Use this notification |
michael@0 | 30 | to make changes that are dependent on what some other listener |
michael@0 | 31 | did during its profile-do-change. For example, to respond to |
michael@0 | 32 | new preferences. |
michael@0 | 33 | |
michael@0 | 34 | "profile-initial-state" |
michael@0 | 35 | Called after all phases of a change have completed. Typically |
michael@0 | 36 | in this phase, an application level observer will open a new window. |
michael@0 | 37 | |
michael@0 | 38 | Contexts for profile changes. These are passed as the someData param to the |
michael@0 | 39 | observer's Observe() method. |
michael@0 | 40 | |
michael@0 | 41 | "startup" |
michael@0 | 42 | Going from no profile to a profile. |
michael@0 | 43 | The following topics happen in this context: |
michael@0 | 44 | profile-do-change |
michael@0 | 45 | profile-after-change |
michael@0 | 46 | |
michael@0 | 47 | "shutdown-persist" |
michael@0 | 48 | The user is logging out and whatever data the observer stores |
michael@0 | 49 | for the current profile should be released from memory and |
michael@0 | 50 | saved to disk. |
michael@0 | 51 | The following topics happen in this context: |
michael@0 | 52 | profile-change-net-teardown |
michael@0 | 53 | profile-change-teardown |
michael@0 | 54 | profile-before-change |
michael@0 | 55 | |
michael@0 | 56 | See https://wiki.mozilla.org/XPCOM_Shutdown for more details about the shutdown |
michael@0 | 57 | process. |
michael@0 | 58 | |
michael@0 | 59 | NOTE: Long ago there was be a "shutdown-cleanse" version of shutdown which was |
michael@0 | 60 | intended to clear profile data. This is no longer sent and observer code should |
michael@0 | 61 | remove support for it. |