gecko-dev/dom/settings/SettingsManager.js

492 строки
18 KiB
JavaScript
Исходник Обычный вид История

/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this file,
* You can obtain one at http://mozilla.org/MPL/2.0/. */
"use strict";
const Cc = Components.classes;
const Ci = Components.interfaces;
const Cu = Components.utils;
Cu.import("resource://gre/modules/XPCOMUtils.jsm");
Cu.import("resource://gre/modules/Services.jsm");
Cu.import("resource://gre/modules/DOMRequestHelper.jsm");
let DEBUG = false;
let VERBOSE = false;
try {
DEBUG =
Services.prefs.getBoolPref("dom.mozSettings.SettingsManager.debug.enabled");
VERBOSE =
Services.prefs.getBoolPref("dom.mozSettings.SettingsManager.verbose.enabled");
} catch (ex) { }
function debug(s) {
dump("-*- SettingsManager: " + s + "\n");
}
2014-08-28 08:01:29 +04:00
XPCOMUtils.defineLazyServiceGetter(Services, "DOMRequest",
"@mozilla.org/dom/dom-request-service;1",
"nsIDOMRequestService");
XPCOMUtils.defineLazyServiceGetter(this, "cpmm",
"@mozilla.org/childprocessmessagemanager;1",
"nsIMessageSender");
XPCOMUtils.defineLazyServiceGetter(this, "mrm",
"@mozilla.org/memory-reporter-manager;1",
"nsIMemoryReporterManager");
2014-08-28 08:01:29 +04:00
XPCOMUtils.defineLazyServiceGetter(this, "uuidgen",
"@mozilla.org/uuid-generator;1",
"nsIUUIDGenerator");
/**
* In order to make SettingsManager work with Privileged Apps, we need the lock
* to be OOP. However, the lock state needs to be managed on the child process,
* while the IDB functions now happen on the parent process so we don't have to
* expose IDB permissions at the child process level. We use the
* DOMRequestHelper mechanism to deal with DOMRequests/promises across the
* processes.
*
* However, due to the nature of the IDBTransaction lifetime, we need to relay
* to the parent when to finalize the transaction once the child is done with the
* lock. We keep a list of all open requests for a lock, and once the lock
* reaches the end of its receiveMessage function with no more queued requests,
* we consider it dead. At that point, we send a message to the parent to notify
* it to finalize the transaction.
*/
function SettingsLock(aSettingsManager) {
if (VERBOSE) debug("settings lock init");
this._open = true;
this._settingsManager = aSettingsManager;
2014-08-28 08:01:29 +04:00
this._id = uuidgen.generateUUID().toString();
// DOMRequestIpcHelper.initHelper sets this._window
this.initDOMRequestHelper(this._settingsManager._window, ["Settings:Get:OK", "Settings:Get:KO",
"Settings:Clear:OK", "Settings:Clear:KO",
"Settings:Set:OK", "Settings:Set:KO",
"Settings:Finalize:OK", "Settings:Finalize:KO"]);
Bug 1082001 - Cleanup settings lock from parent itself. r=bent From bug 1065128 SettingsManager has been changed to listen the dom-window-destroyed event for its cleanup. However, when running Gaia in Mulet, a race condition is exposed. For B2G, when loading a page, about:blank is first used. This means that window destroyed events will be triggered. However, from the dom-window-destroyed event we cannot distinguish whether this is about:blank or a legit application being closed. SettingsManager gets initialized (i.e., init() called) when the application makes use of navigator.mozSettings. So the chain of event is that we have a SettingsManager living because System app did some request. At this time, about:blank is being unloaded and triggers a dom-window-destroyed event. This makes SettingsManager doing its cleanup, especially freeing the window reference. Then in the meantime, we have the navigator.mozSettings use that is progressing. At some point, SettingsManager has no more window to send messages to, and Gaia is not able to even start. SettingsRequestManager lives on the parent process and SettingsManager lives on the child side. Part of the cleanup performed by SettingsManager was to ensure pending locks on the parent process would be forced to finalize to make sure those are being properly committed. We move this cleanup to SettingsRequestManager and we augment the lock informations with the proper inner window id. This way we can track which lock is attached to which inner window when the lock gets created. And thus we can listen on inner-window-destroyed from SettingsRequestManager to be able to force finalize on any pending lock. Impacted code path are those were we are not running out of process. When we are running out of process, SettingsRequestManager already listens on the child-process-shutdown event to perform the lock finalization.
2014-10-29 09:36:00 +03:00
let createLockPayload = {
lockID: this._id,
isServiceLock: false,
windowID: this._settingsManager.innerWindowID,
lockStack: (new Error).stack
Bug 1082001 - Cleanup settings lock from parent itself. r=bent From bug 1065128 SettingsManager has been changed to listen the dom-window-destroyed event for its cleanup. However, when running Gaia in Mulet, a race condition is exposed. For B2G, when loading a page, about:blank is first used. This means that window destroyed events will be triggered. However, from the dom-window-destroyed event we cannot distinguish whether this is about:blank or a legit application being closed. SettingsManager gets initialized (i.e., init() called) when the application makes use of navigator.mozSettings. So the chain of event is that we have a SettingsManager living because System app did some request. At this time, about:blank is being unloaded and triggers a dom-window-destroyed event. This makes SettingsManager doing its cleanup, especially freeing the window reference. Then in the meantime, we have the navigator.mozSettings use that is progressing. At some point, SettingsManager has no more window to send messages to, and Gaia is not able to even start. SettingsRequestManager lives on the parent process and SettingsManager lives on the child side. Part of the cleanup performed by SettingsManager was to ensure pending locks on the parent process would be forced to finalize to make sure those are being properly committed. We move this cleanup to SettingsRequestManager and we augment the lock informations with the proper inner window id. This way we can track which lock is attached to which inner window when the lock gets created. And thus we can listen on inner-window-destroyed from SettingsRequestManager to be able to force finalize on any pending lock. Impacted code path are those were we are not running out of process. When we are running out of process, SettingsRequestManager already listens on the child-process-shutdown event to perform the lock finalization.
2014-10-29 09:36:00 +03:00
};
this.sendMessage("Settings:CreateLock", createLockPayload);
2014-08-28 08:01:29 +04:00
Services.tm.currentThread.dispatch(this._closeHelper.bind(this), Ci.nsIThread.DISPATCH_NORMAL);
// We only want to file closeHelper once per set of receiveMessage calls.
this._closeCalled = true;
}
SettingsLock.prototype = {
2014-08-28 08:01:29 +04:00
__proto__: DOMRequestIpcHelper.prototype,
set onsettingstransactionsuccess(aHandler) {
this.__DOM_IMPL__.setEventHandler("onsettingstransactionsuccess", aHandler);
},
get onsettingstransactionsuccess() {
return this.__DOM_IMPL__.getEventHandler("onsettingstransactionsuccess");
},
set onsettingstransactionfailure(aHandler) {
this.__DOM_IMPL__.setEventHandler("onsettingstransactionfailure", aHandler);
},
get onsettingstransactionfailure() {
return this.__DOM_IMPL__.getEventHandler("onsettingstransactionfailure");
},
get closed() {
return !this._open;
},
2014-08-28 08:01:29 +04:00
_closeHelper: function() {
if (VERBOSE) debug("closing lock " + this._id);
2014-08-28 08:01:29 +04:00
this._open = false;
this._closeCalled = false;
2014-08-28 08:01:29 +04:00
if (!this._requests || Object.keys(this._requests).length == 0) {
if (VERBOSE) debug("Requests exhausted, finalizing " + this._id);
2014-08-28 08:01:29 +04:00
this._settingsManager.unregisterLock(this._id);
this.sendMessage("Settings:Finalize", {lockID: this._id});
} else {
if (VERBOSE) debug("Requests left: " + Object.keys(this._requests).length);
2014-08-28 08:01:29 +04:00
this.sendMessage("Settings:Run", {lockID: this._id});
}
},
2014-08-28 08:01:29 +04:00
_wrap: function _wrap(obj) {
return Cu.cloneInto(obj, this._settingsManager._window);
},
2014-08-28 08:01:29 +04:00
sendMessage: function(aMessageName, aData) {
// sendMessage can be called after our window has died, or get
// queued to run later in a thread via _closeHelper, but the
// SettingsManager may have died in between the time it was
// scheduled and the time it runs. Make sure our window is valid
// before sending, otherwise just ignore.
if (!this._settingsManager._window) {
Cu.reportError(
"SettingsManager window died, cannot run settings transaction." +
" SettingsMessage: " + aMessageName +
" SettingsData: " + JSON.stringify(aData));
return;
}
2014-08-28 08:01:29 +04:00
cpmm.sendAsyncMessage(aMessageName,
aData,
undefined,
this._settingsManager._window.document.nodePrincipal);
},
2014-08-28 08:01:29 +04:00
receiveMessage: function(aMessage) {
let msg = aMessage.data;
2014-08-28 08:01:29 +04:00
// SettingsRequestManager broadcasts changes to all locks in the child. If
// our lock isn't being addressed, just return.
if (msg.lockID != this._id) {
return;
}
if (VERBOSE) debug("receiveMessage (" + this._id + "): " + aMessage.name);
2014-08-28 08:01:29 +04:00
// Finalizing a transaction does not return a request ID since we are
// supposed to fire callbacks.
//
// We also destroy the DOMRequestHelper after we've received the
// finalize message. At this point, we will be guarenteed no more
// request returns are coming from the SettingsRequestManager.
2014-08-28 08:01:29 +04:00
if (!msg.requestID) {
let event;
switch (aMessage.name) {
case "Settings:Finalize:OK":
if (VERBOSE) debug("Lock finalize ok: " + this._id);
2014-08-28 08:01:29 +04:00
event = new this._window.MozSettingsTransactionEvent("settingstransactionsuccess", {});
this.__DOM_IMPL__.dispatchEvent(event);
this.destroyDOMRequestHelper();
2014-08-28 08:01:29 +04:00
break;
case "Settings:Finalize:KO":
if (DEBUG) debug("Lock finalize failed: " + this._id);
event = new this._window.MozSettingsTransactionEvent("settingstransactionfailure", {
error: msg.errorMsg
});
this.__DOM_IMPL__.dispatchEvent(event);
this.destroyDOMRequestHelper();
2014-08-28 08:01:29 +04:00
break;
default:
if (DEBUG) debug("Message type " + aMessage.name + " is missing a requestID");
}
return;
}
2014-08-28 08:01:29 +04:00
let req = this.getRequest(msg.requestID);
if (!req) {
if (DEBUG) debug("Matching request not found.");
return;
}
2014-08-28 08:01:29 +04:00
this.removeRequest(msg.requestID);
// DOMRequest callbacks called from here can die due to having
// things like marionetteScriptFinished in them. Make sure we file
// our call to run/finalize BEFORE opening the lock and fulfilling
// DOMRequests.
if (!this._closeCalled) {
// We only want to file closeHelper once per set of receiveMessage calls.
Services.tm.currentThread.dispatch(this._closeHelper.bind(this), Ci.nsIThread.DISPATCH_NORMAL);
this._closeCalled = true;
}
if (VERBOSE) debug("receiveMessage: " + aMessage.name);
2014-08-28 08:01:29 +04:00
switch (aMessage.name) {
case "Settings:Get:OK":
for (let i in msg.settings) {
msg.settings[i] = this._wrap(msg.settings[i]);
}
this._open = true;
2014-08-28 08:01:29 +04:00
Services.DOMRequest.fireSuccess(req.request, this._wrap(msg.settings));
this._open = false;
2014-08-28 08:01:29 +04:00
break;
2014-08-28 08:01:29 +04:00
case "Settings:Set:OK":
case "Settings:Clear:OK":
this._open = true;
Services.DOMRequest.fireSuccess(req.request, 0);
this._open = false;
break;
case "Settings:Get:KO":
case "Settings:Set:KO":
case "Settings:Clear:KO":
if (DEBUG) debug("error:" + msg.errorMsg);
Services.DOMRequest.fireError(req.request, msg.errorMsg);
break;
default:
if (DEBUG) debug("Wrong message: " + aMessage.name);
2014-08-28 08:01:29 +04:00
}
},
get: function get(aName) {
if (VERBOSE) debug("get (" + this._id + "): " + aName);
if (!this._open) {
dump("Settings lock not open!\n");
throw Components.results.NS_ERROR_ABORT;
}
2014-08-28 08:01:29 +04:00
let req = this.createRequest();
let reqID = this.getRequestId({request: req});
this.sendMessage("Settings:Get", {requestID: reqID,
lockID: this._id,
name: aName});
return req;
},
set: function set(aSettings) {
if (VERBOSE) debug("send: " + JSON.stringify(aSettings));
if (!this._open) {
throw "Settings lock not open";
}
2014-08-28 08:01:29 +04:00
let req = this.createRequest();
let reqID = this.getRequestId({request: req});
this.sendMessage("Settings:Set", {requestID: reqID,
lockID: this._id,
settings: aSettings});
return req;
},
clear: function clear() {
if (VERBOSE) debug("clear");
if (!this._open) {
throw "Settings lock not open";
}
2014-08-28 08:01:29 +04:00
let req = this.createRequest();
let reqID = this.getRequestId({request: req});
this.sendMessage("Settings:Clear", {requestID: reqID,
lockID: this._id});
return req;
},
classID: Components.ID("{60c9357c-3ae0-4222-8f55-da01428470d5}"),
contractID: "@mozilla.org/settingsLock;1",
2014-08-28 08:01:29 +04:00
QueryInterface: XPCOMUtils.generateQI([Ci.nsISupports,
Ci.nsIObserver,
Ci.nsISupportsWeakReference])
};
function SettingsManager() {
2014-08-28 08:01:29 +04:00
this._callbacks = null;
this._isRegistered = false;
this._locks = [];
this._createdLocks = 0;
this._unregisteredLocks = 0;
}
SettingsManager.prototype = {
_wrap: function _wrap(obj) {
return Cu.cloneInto(obj, this._window);
},
set onsettingchange(aHandler) {
this.__DOM_IMPL__.setEventHandler("onsettingchange", aHandler);
2014-08-28 08:01:29 +04:00
this.checkMessageRegistration();
},
get onsettingchange() {
return this.__DOM_IMPL__.getEventHandler("onsettingchange");
},
createLock: function() {
2014-08-28 08:01:29 +04:00
let lock = new SettingsLock(this);
if (VERBOSE) debug("creating lock " + lock._id);
2014-08-28 08:01:29 +04:00
this._locks.push(lock._id);
this._createdLocks++;
return lock;
},
2014-08-28 08:01:29 +04:00
unregisterLock: function(aLockID) {
let lock_index = this._locks.indexOf(aLockID);
if (lock_index != -1) {
if (VERBOSE) debug("Unregistering lock " + aLockID);
this._locks.splice(lock_index, 1);
this._unregisteredLocks++;
2014-08-28 08:01:29 +04:00
}
},
receiveMessage: function(aMessage) {
if (VERBOSE) debug("Settings::receiveMessage: " + aMessage.name);
let msg = aMessage.json;
switch (aMessage.name) {
case "Settings:Change:Return:OK":
if (VERBOSE) debug('data:' + msg.key + ':' + msg.value + '\n');
let event = new this._window.MozSettingsEvent("settingchange", this._wrap({
settingName: msg.key,
settingValue: msg.value
}));
this.__DOM_IMPL__.dispatchEvent(event);
if (this._callbacks && this._callbacks[msg.key]) {
if (VERBOSE) debug("observe callback called! " + msg.key + " " + this._callbacks[msg.key].length);
this._callbacks[msg.key].forEach(function(cb) {
cb(this._wrap({settingName: msg.key, settingValue: msg.value}));
}.bind(this));
} else {
if (VERBOSE) debug("no observers stored!");
}
break;
default:
if (DEBUG) debug("Wrong message: " + aMessage.name);
}
},
2014-08-28 08:01:29 +04:00
// If we have either observer callbacks or an event handler,
// register for messages from the main thread. Otherwise, if no one
// is listening, unregister to reduce parent load.
checkMessageRegistration: function checkRegistration() {
let handler = this.__DOM_IMPL__.getEventHandler("onsettingchange");
if (!this._isRegistered) {
if (VERBOSE) debug("Registering for messages");
2014-08-28 08:01:29 +04:00
cpmm.sendAsyncMessage("Settings:RegisterForMessages",
undefined,
undefined,
this._window.document.nodePrincipal);
this._isRegistered = true;
} else {
if ((!this._callbacks || Object.keys(this._callbacks).length == 0) &&
!handler) {
if (VERBOSE) debug("Unregistering for messages");
2014-08-28 08:01:29 +04:00
cpmm.sendAsyncMessage("Settings:UnregisterForMessages",
undefined,
undefined,
this._window.document.nodePrincipal);
this._isRegistered = false;
this._callbacks = null;
}
}
},
addObserver: function addObserver(aName, aCallback) {
if (VERBOSE) debug("addObserver " + aName);
if (!this._callbacks) {
this._callbacks = {};
}
if (!this._callbacks[aName]) {
this._callbacks[aName] = [aCallback];
} else {
this._callbacks[aName].push(aCallback);
}
2014-08-28 08:01:29 +04:00
this.checkMessageRegistration();
},
removeObserver: function removeObserver(aName, aCallback) {
if (VERBOSE) debug("deleteObserver " + aName);
if (this._callbacks && this._callbacks[aName]) {
let index = this._callbacks[aName].indexOf(aCallback);
if (index != -1) {
this._callbacks[aName].splice(index, 1);
2014-08-28 08:01:29 +04:00
if (this._callbacks[aName].length == 0) {
delete this._callbacks[aName];
}
} else {
if (VERBOSE) debug("Callback not found for: " + aName);
}
} else {
if (VERBOSE) debug("No observers stored for " + aName);
}
2014-08-28 08:01:29 +04:00
this.checkMessageRegistration();
},
init: function(aWindow) {
if (VERBOSE) debug("SettingsManager init");
mrm.registerStrongReporter(this);
cpmm.addMessageListener("Settings:Change:Return:OK", this);
Bug 1082001 - Cleanup settings lock from parent itself. r=bent From bug 1065128 SettingsManager has been changed to listen the dom-window-destroyed event for its cleanup. However, when running Gaia in Mulet, a race condition is exposed. For B2G, when loading a page, about:blank is first used. This means that window destroyed events will be triggered. However, from the dom-window-destroyed event we cannot distinguish whether this is about:blank or a legit application being closed. SettingsManager gets initialized (i.e., init() called) when the application makes use of navigator.mozSettings. So the chain of event is that we have a SettingsManager living because System app did some request. At this time, about:blank is being unloaded and triggers a dom-window-destroyed event. This makes SettingsManager doing its cleanup, especially freeing the window reference. Then in the meantime, we have the navigator.mozSettings use that is progressing. At some point, SettingsManager has no more window to send messages to, and Gaia is not able to even start. SettingsRequestManager lives on the parent process and SettingsManager lives on the child side. Part of the cleanup performed by SettingsManager was to ensure pending locks on the parent process would be forced to finalize to make sure those are being properly committed. We move this cleanup to SettingsRequestManager and we augment the lock informations with the proper inner window id. This way we can track which lock is attached to which inner window when the lock gets created. And thus we can listen on inner-window-destroyed from SettingsRequestManager to be able to force finalize on any pending lock. Impacted code path are those were we are not running out of process. When we are running out of process, SettingsRequestManager already listens on the child-process-shutdown event to perform the lock finalization.
2014-10-29 09:36:00 +03:00
Services.obs.addObserver(this, "inner-window-destroyed", false);
let util = aWindow.QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.nsIDOMWindowUtils);
this.innerWindowID = util.currentInnerWindowID;
Bug 1082001 - Cleanup settings lock from parent itself. r=bent From bug 1065128 SettingsManager has been changed to listen the dom-window-destroyed event for its cleanup. However, when running Gaia in Mulet, a race condition is exposed. For B2G, when loading a page, about:blank is first used. This means that window destroyed events will be triggered. However, from the dom-window-destroyed event we cannot distinguish whether this is about:blank or a legit application being closed. SettingsManager gets initialized (i.e., init() called) when the application makes use of navigator.mozSettings. So the chain of event is that we have a SettingsManager living because System app did some request. At this time, about:blank is being unloaded and triggers a dom-window-destroyed event. This makes SettingsManager doing its cleanup, especially freeing the window reference. Then in the meantime, we have the navigator.mozSettings use that is progressing. At some point, SettingsManager has no more window to send messages to, and Gaia is not able to even start. SettingsRequestManager lives on the parent process and SettingsManager lives on the child side. Part of the cleanup performed by SettingsManager was to ensure pending locks on the parent process would be forced to finalize to make sure those are being properly committed. We move this cleanup to SettingsRequestManager and we augment the lock informations with the proper inner window id. This way we can track which lock is attached to which inner window when the lock gets created. And thus we can listen on inner-window-destroyed from SettingsRequestManager to be able to force finalize on any pending lock. Impacted code path are those were we are not running out of process. When we are running out of process, SettingsRequestManager already listens on the child-process-shutdown event to perform the lock finalization.
2014-10-29 09:36:00 +03:00
this._window = aWindow;
},
observe: function(aSubject, aTopic, aData) {
if (VERBOSE) debug("Topic: " + aTopic);
Bug 1082001 - Cleanup settings lock from parent itself. r=bent From bug 1065128 SettingsManager has been changed to listen the dom-window-destroyed event for its cleanup. However, when running Gaia in Mulet, a race condition is exposed. For B2G, when loading a page, about:blank is first used. This means that window destroyed events will be triggered. However, from the dom-window-destroyed event we cannot distinguish whether this is about:blank or a legit application being closed. SettingsManager gets initialized (i.e., init() called) when the application makes use of navigator.mozSettings. So the chain of event is that we have a SettingsManager living because System app did some request. At this time, about:blank is being unloaded and triggers a dom-window-destroyed event. This makes SettingsManager doing its cleanup, especially freeing the window reference. Then in the meantime, we have the navigator.mozSettings use that is progressing. At some point, SettingsManager has no more window to send messages to, and Gaia is not able to even start. SettingsRequestManager lives on the parent process and SettingsManager lives on the child side. Part of the cleanup performed by SettingsManager was to ensure pending locks on the parent process would be forced to finalize to make sure those are being properly committed. We move this cleanup to SettingsRequestManager and we augment the lock informations with the proper inner window id. This way we can track which lock is attached to which inner window when the lock gets created. And thus we can listen on inner-window-destroyed from SettingsRequestManager to be able to force finalize on any pending lock. Impacted code path are those were we are not running out of process. When we are running out of process, SettingsRequestManager already listens on the child-process-shutdown event to perform the lock finalization.
2014-10-29 09:36:00 +03:00
if (aTopic === "inner-window-destroyed") {
let wId = aSubject.QueryInterface(Ci.nsISupportsPRUint64).data;
if (wId === this.innerWindowID) {
if (DEBUG) debug("Received: inner-window-destroyed for valid innerWindowID=" + wId + ", cleanup.");
this.cleanup();
}
}
},
collectReports: function(aCallback, aData, aAnonymize) {
2014-08-28 08:01:29 +04:00
for (let topic in this._callbacks) {
let length = this._callbacks[topic].length;
if (length == 0) {
continue;
}
let path;
if (length < 20) {
path = "settings-observers";
} else {
path = "settings-observers-suspect/referent(topic=" +
(aAnonymize ? "<anonymized>" : topic) + ")";
}
aCallback.callback("", path,
Ci.nsIMemoryReporter.KIND_OTHER,
Ci.nsIMemoryReporter.UNITS_COUNT,
length,
"The number of settings observers for this topic.",
aData);
}
aCallback.callback("",
"settings-locks/alive",
Ci.nsIMemoryReporter.KIND_OTHER,
Ci.nsIMemoryReporter.UNITS_COUNT,
this._locks.length,
"The number of locks that are currently alives.",
aData);
aCallback.callback("",
"settings-locks/created",
Ci.nsIMemoryReporter.KIND_OTHER,
Ci.nsIMemoryReporter.UNITS_COUNT,
this._createdLocks,
"The number of locks that were created.",
aData);
aCallback.callback("",
"settings-locks/deleted",
Ci.nsIMemoryReporter.KIND_OTHER,
Ci.nsIMemoryReporter.UNITS_COUNT,
this._unregisteredLocks,
"The number of locks that were deleted.",
aData);
},
cleanup: function() {
Bug 1082001 - Cleanup settings lock from parent itself. r=bent From bug 1065128 SettingsManager has been changed to listen the dom-window-destroyed event for its cleanup. However, when running Gaia in Mulet, a race condition is exposed. For B2G, when loading a page, about:blank is first used. This means that window destroyed events will be triggered. However, from the dom-window-destroyed event we cannot distinguish whether this is about:blank or a legit application being closed. SettingsManager gets initialized (i.e., init() called) when the application makes use of navigator.mozSettings. So the chain of event is that we have a SettingsManager living because System app did some request. At this time, about:blank is being unloaded and triggers a dom-window-destroyed event. This makes SettingsManager doing its cleanup, especially freeing the window reference. Then in the meantime, we have the navigator.mozSettings use that is progressing. At some point, SettingsManager has no more window to send messages to, and Gaia is not able to even start. SettingsRequestManager lives on the parent process and SettingsManager lives on the child side. Part of the cleanup performed by SettingsManager was to ensure pending locks on the parent process would be forced to finalize to make sure those are being properly committed. We move this cleanup to SettingsRequestManager and we augment the lock informations with the proper inner window id. This way we can track which lock is attached to which inner window when the lock gets created. And thus we can listen on inner-window-destroyed from SettingsRequestManager to be able to force finalize on any pending lock. Impacted code path are those were we are not running out of process. When we are running out of process, SettingsRequestManager already listens on the child-process-shutdown event to perform the lock finalization.
2014-10-29 09:36:00 +03:00
Services.obs.removeObserver(this, "inner-window-destroyed");
// At this point, the window is dying, so there's nothing left
// that we could do with our lock. Go ahead and run finalize on
// it to make sure changes are commited.
for (let i = 0; i < this._locks.length; ++i) {
if (DEBUG) debug("Lock alive at destroy, finalizing: " + this._locks[i]);
// Due to bug 1105511 we should be able to send this without
// cached principals. However, this is scary because any iframe
// in the process could run this?
cpmm.sendAsyncMessage("Settings:Finalize",
{lockID: this._locks[i]});
}
cpmm.removeMessageListener("Settings:Change:Return:OK", this);
mrm.unregisterStrongReporter(this);
Bug 1082001 - Cleanup settings lock from parent itself. r=bent From bug 1065128 SettingsManager has been changed to listen the dom-window-destroyed event for its cleanup. However, when running Gaia in Mulet, a race condition is exposed. For B2G, when loading a page, about:blank is first used. This means that window destroyed events will be triggered. However, from the dom-window-destroyed event we cannot distinguish whether this is about:blank or a legit application being closed. SettingsManager gets initialized (i.e., init() called) when the application makes use of navigator.mozSettings. So the chain of event is that we have a SettingsManager living because System app did some request. At this time, about:blank is being unloaded and triggers a dom-window-destroyed event. This makes SettingsManager doing its cleanup, especially freeing the window reference. Then in the meantime, we have the navigator.mozSettings use that is progressing. At some point, SettingsManager has no more window to send messages to, and Gaia is not able to even start. SettingsRequestManager lives on the parent process and SettingsManager lives on the child side. Part of the cleanup performed by SettingsManager was to ensure pending locks on the parent process would be forced to finalize to make sure those are being properly committed. We move this cleanup to SettingsRequestManager and we augment the lock informations with the proper inner window id. This way we can track which lock is attached to which inner window when the lock gets created. And thus we can listen on inner-window-destroyed from SettingsRequestManager to be able to force finalize on any pending lock. Impacted code path are those were we are not running out of process. When we are running out of process, SettingsRequestManager already listens on the child-process-shutdown event to perform the lock finalization.
2014-10-29 09:36:00 +03:00
this.innerWindowID = null;
this._window = null;
},
classID: Components.ID("{c40b1c70-00fb-11e2-a21f-0800200c9a66}"),
contractID: "@mozilla.org/settingsManager;1",
QueryInterface: XPCOMUtils.generateQI([Ci.nsISupports,
Ci.nsIDOMGlobalPropertyInitializer,
Ci.nsIObserver,
Ci.nsIMemoryReporter]),
};
this.NSGetFactory = XPCOMUtils.generateNSGetFactory([SettingsManager, SettingsLock]);