Wed, 31 Dec 2014 13:27:57 +0100
Ignore runtime configuration files generated during quality assurance.
michael@0 | 1 | /* -*- Mode: IDL; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */ |
michael@0 | 2 | /* This Source Code Form is subject to the terms of the Mozilla Public |
michael@0 | 3 | * License, v. 2.0. If a copy of the MPL was not distributed with this |
michael@0 | 4 | * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ |
michael@0 | 5 | |
michael@0 | 6 | #include "nsISupports.idl" |
michael@0 | 7 | |
michael@0 | 8 | interface nsIDOMWindow; |
michael@0 | 9 | interface nsIDocShell; |
michael@0 | 10 | interface nsIContent; |
michael@0 | 11 | interface nsIPrincipal; |
michael@0 | 12 | |
michael@0 | 13 | /** |
michael@0 | 14 | * Message managers provide a way for chrome-privileged JS code to |
michael@0 | 15 | * communicate with each other, even across process boundaries. |
michael@0 | 16 | * |
michael@0 | 17 | * Message managers are separated into "parent side" and "child side". |
michael@0 | 18 | * These don't always correspond to process boundaries, but can. For |
michael@0 | 19 | * each child-side message manager, there is always exactly one |
michael@0 | 20 | * corresponding parent-side message manager that it sends messages |
michael@0 | 21 | * to. However, for each parent-side message manager, there may be |
michael@0 | 22 | * either one or many child-side managers it can message. |
michael@0 | 23 | * |
michael@0 | 24 | * Message managers that always have exactly one "other side" are of |
michael@0 | 25 | * type nsIMessageSender. Parent-side message managers that have many |
michael@0 | 26 | * "other sides" are of type nsIMessageBroadcaster. |
michael@0 | 27 | * |
michael@0 | 28 | * Child-side message managers can send synchronous messages to their |
michael@0 | 29 | * parent side, but not the other way around. |
michael@0 | 30 | * |
michael@0 | 31 | * There are two realms of message manager hierarchies. One realm |
michael@0 | 32 | * approximately corresponds to DOM elements, the other corresponds to |
michael@0 | 33 | * process boundaries. |
michael@0 | 34 | * |
michael@0 | 35 | * Message managers corresponding to DOM elements |
michael@0 | 36 | * ============================================== |
michael@0 | 37 | * |
michael@0 | 38 | * In this realm of message managers, there are |
michael@0 | 39 | * - "frame message managers" which correspond to frame elements |
michael@0 | 40 | * - "window message managers" which correspond to top-level chrome |
michael@0 | 41 | * windows |
michael@0 | 42 | * - the "global message manager", on the parent side. See below. |
michael@0 | 43 | * |
michael@0 | 44 | * The DOM-realm message managers can communicate in the ways shown by |
michael@0 | 45 | * the following diagram. The parent side and child side can |
michael@0 | 46 | * correspond to process boundaries, but don't always. |
michael@0 | 47 | * |
michael@0 | 48 | * Parent side Child side |
michael@0 | 49 | * ------------- ------------ |
michael@0 | 50 | * global MMg |
michael@0 | 51 | * | |
michael@0 | 52 | * +-->window MMw1 |
michael@0 | 53 | * | | |
michael@0 | 54 | * | +-->frame MMp1_1<------------>frame MMc1_1 |
michael@0 | 55 | * | | |
michael@0 | 56 | * | +-->frame MMp1_2<------------>frame MMc1_2 |
michael@0 | 57 | * | ... |
michael@0 | 58 | * | |
michael@0 | 59 | * +-->window MMw2 |
michael@0 | 60 | * ... |
michael@0 | 61 | * |
michael@0 | 62 | * For example: a message sent from MMc1_1, from the child side, is |
michael@0 | 63 | * sent only to MMp1_1 on the parent side. However, note that all |
michael@0 | 64 | * message managers in the hierarchy above MMp1_1, in this diagram |
michael@0 | 65 | * MMw1 and MMg, will also notify their message listeners when the |
michael@0 | 66 | * message arrives. |
michael@0 | 67 | |
michael@0 | 68 | * For example: a message broadcast through the global MMg on the |
michael@0 | 69 | * parent side would be broadcast to MMw1, which would transitively |
michael@0 | 70 | * broadcast it to MMp1_1, MM1p_2". The message would next be |
michael@0 | 71 | * broadcast to MMw2, and so on down the hierarchy. |
michael@0 | 72 | * |
michael@0 | 73 | * ***** PERFORMANCE AND SECURITY WARNING ***** |
michael@0 | 74 | * Messages broadcast through the global MM and window MMs can result |
michael@0 | 75 | * in messages being dispatched across many OS processes, and to many |
michael@0 | 76 | * processes with different permissions. Great care should be taken |
michael@0 | 77 | * when broadcasting. |
michael@0 | 78 | * |
michael@0 | 79 | * Interfaces |
michael@0 | 80 | * ---------- |
michael@0 | 81 | * |
michael@0 | 82 | * The global MMg and window MMw's are message broadcasters implementing |
michael@0 | 83 | * nsIMessageBroadcaster while the frame MMp's are simple message senders |
michael@0 | 84 | * (nsIMessageSender). Their counterparts in the content processes are |
michael@0 | 85 | * message senders implementing nsIContentFrameMessageManager. |
michael@0 | 86 | * |
michael@0 | 87 | * nsIMessageListenerManager |
michael@0 | 88 | * / \ |
michael@0 | 89 | * nsIMessageSender nsIMessageBroadcaster |
michael@0 | 90 | * | |
michael@0 | 91 | * nsISyncMessageSender (content process/in-process only) |
michael@0 | 92 | * | |
michael@0 | 93 | * nsIContentFrameMessageManager (content process/in-process only) |
michael@0 | 94 | * | |
michael@0 | 95 | * nsIInProcessContentFrameMessageManager (in-process only) |
michael@0 | 96 | * |
michael@0 | 97 | * |
michael@0 | 98 | * Message managers in the chrome process can also be QI'ed to nsIFrameScriptLoader. |
michael@0 | 99 | * |
michael@0 | 100 | * |
michael@0 | 101 | * Message managers corresponding to process boundaries |
michael@0 | 102 | * ==================================================== |
michael@0 | 103 | * |
michael@0 | 104 | * The second realm of message managers is the "process message |
michael@0 | 105 | * managers". With one exception, these always correspond to process |
michael@0 | 106 | * boundaries. The picture looks like |
michael@0 | 107 | * |
michael@0 | 108 | * Parent process Child processes |
michael@0 | 109 | * ---------------- ----------------- |
michael@0 | 110 | * global PPMM |
michael@0 | 111 | * | |
michael@0 | 112 | * +<----> child PPMM |
michael@0 | 113 | * | |
michael@0 | 114 | * +-->parent PMM1<------------------>child process CMM1 |
michael@0 | 115 | * | |
michael@0 | 116 | * +-->parent PMM2<------------------>child process PMM2 |
michael@0 | 117 | * ... |
michael@0 | 118 | * |
michael@0 | 119 | * For example: the parent-process PMM1 sends messages directly to |
michael@0 | 120 | * only the child-process CMM1. |
michael@0 | 121 | * |
michael@0 | 122 | * For example: CMM1 sends messages directly to PMM1. The global PPMM |
michael@0 | 123 | * will also notify their message listeners when the message arrives. |
michael@0 | 124 | * |
michael@0 | 125 | * For example: messages sent through the global PPMM will be |
michael@0 | 126 | * dispatched to the listeners of the same-process, "child PPMM". |
michael@0 | 127 | * They will also be broadcast to PPM1, PPM2, etc. |
michael@0 | 128 | * |
michael@0 | 129 | * ***** PERFORMANCE AND SECURITY WARNING ***** |
michael@0 | 130 | * Messages broadcast through the global PPMM can result in messages |
michael@0 | 131 | * being dispatched across many OS processes, and to many processes |
michael@0 | 132 | * with different permissions. Great care should be taken when |
michael@0 | 133 | * broadcasting. |
michael@0 | 134 | * |
michael@0 | 135 | * Requests sent to parent-process message listeners should usually |
michael@0 | 136 | * have replies scoped to the requesting CPMM. The following pattern |
michael@0 | 137 | * is common |
michael@0 | 138 | * |
michael@0 | 139 | * const ParentProcessListener = { |
michael@0 | 140 | * receiveMessage: function(aMessage) { |
michael@0 | 141 | * let childMM = aMessage.target.QueryInterface(Ci.nsIMessageSender); |
michael@0 | 142 | * switch (aMessage.name) { |
michael@0 | 143 | * case "Foo:Request": |
michael@0 | 144 | * // service request |
michael@0 | 145 | * childMM.sendAsyncMessage("Foo:Response", { data }); |
michael@0 | 146 | * } |
michael@0 | 147 | * } |
michael@0 | 148 | * }; |
michael@0 | 149 | */ |
michael@0 | 150 | |
michael@0 | 151 | [scriptable, function, uuid(2b44eb57-a9c6-4773-9a1e-fe0818739a4c)] |
michael@0 | 152 | interface nsIMessageListener : nsISupports |
michael@0 | 153 | { |
michael@0 | 154 | /** |
michael@0 | 155 | * This is for JS only. |
michael@0 | 156 | * receiveMessage is called with one parameter, which has the following |
michael@0 | 157 | * properties: |
michael@0 | 158 | * { |
michael@0 | 159 | * target: %the target of the message. Either an element owning |
michael@0 | 160 | * the message manager, or message manager itself if no |
michael@0 | 161 | * element owns it% |
michael@0 | 162 | * name: %message name%, |
michael@0 | 163 | * sync: %true or false%. |
michael@0 | 164 | * data: %structured clone of the sent message data%, |
michael@0 | 165 | * json: %same as .data, deprecated%, |
michael@0 | 166 | * objects: %named table of jsvals/objects, or null% |
michael@0 | 167 | * principal: %principal for the window app |
michael@0 | 168 | * } |
michael@0 | 169 | * |
michael@0 | 170 | * Each listener is invoked with its own copy of the message |
michael@0 | 171 | * parameter. |
michael@0 | 172 | * |
michael@0 | 173 | * When the listener is called, 'this' value is the target of the message. |
michael@0 | 174 | * |
michael@0 | 175 | * If the message is synchronous, the possible return value is |
michael@0 | 176 | * returned as JSON (will be changed to use structured clones). |
michael@0 | 177 | * When there are multiple listeners to sync messages, each |
michael@0 | 178 | * listener's return value is sent back as an array. |undefined| |
michael@0 | 179 | * return values show up as undefined values in the array. |
michael@0 | 180 | */ |
michael@0 | 181 | void receiveMessage(); |
michael@0 | 182 | }; |
michael@0 | 183 | |
michael@0 | 184 | [scriptable, builtinclass, uuid(aae827bd-acf1-45fe-a556-ea545d4c0804)] |
michael@0 | 185 | interface nsIMessageListenerManager : nsISupports |
michael@0 | 186 | { |
michael@0 | 187 | /** |
michael@0 | 188 | * Register |listener| to receive |messageName|. All listener |
michael@0 | 189 | * callbacks for a particular message are invoked when that message |
michael@0 | 190 | * is received. |
michael@0 | 191 | * |
michael@0 | 192 | * The message manager holds a strong ref to |listener|. |
michael@0 | 193 | * |
michael@0 | 194 | * If the same listener registers twice for the same message, the |
michael@0 | 195 | * second registration is ignored. |
michael@0 | 196 | */ |
michael@0 | 197 | void addMessageListener(in AString messageName, |
michael@0 | 198 | in nsIMessageListener listener); |
michael@0 | 199 | |
michael@0 | 200 | /** |
michael@0 | 201 | * Undo an |addMessageListener| call -- that is, calling this causes us to no |
michael@0 | 202 | * longer invoke |listener| when |messageName| is received. |
michael@0 | 203 | * |
michael@0 | 204 | * removeMessageListener does not remove a message listener added via |
michael@0 | 205 | * addWeakMessageListener; use removeWeakMessageListener for that. |
michael@0 | 206 | */ |
michael@0 | 207 | void removeMessageListener(in AString messageName, |
michael@0 | 208 | in nsIMessageListener listener); |
michael@0 | 209 | |
michael@0 | 210 | /** |
michael@0 | 211 | * This is just like addMessageListener, except the message manager holds a |
michael@0 | 212 | * weak ref to |listener|. |
michael@0 | 213 | * |
michael@0 | 214 | * If you have two weak message listeners for the same message, they may be |
michael@0 | 215 | * called in any order. |
michael@0 | 216 | */ |
michael@0 | 217 | void addWeakMessageListener(in AString messageName, |
michael@0 | 218 | in nsIMessageListener listener); |
michael@0 | 219 | |
michael@0 | 220 | /** |
michael@0 | 221 | * This undoes an |addWeakMessageListener| call. |
michael@0 | 222 | */ |
michael@0 | 223 | void removeWeakMessageListener(in AString messageName, |
michael@0 | 224 | in nsIMessageListener listener); |
michael@0 | 225 | |
michael@0 | 226 | [notxpcom] boolean markForCC(); |
michael@0 | 227 | }; |
michael@0 | 228 | |
michael@0 | 229 | /** |
michael@0 | 230 | * Message "senders" have a single "other side" to which messages are |
michael@0 | 231 | * sent. For example, a child-process message manager will send |
michael@0 | 232 | * messages that are only delivered to its one parent-process message |
michael@0 | 233 | * manager. |
michael@0 | 234 | */ |
michael@0 | 235 | [scriptable, builtinclass, uuid(d6b0d851-43e6-426d-9f13-054bc0198175)] |
michael@0 | 236 | interface nsIMessageSender : nsIMessageListenerManager |
michael@0 | 237 | { |
michael@0 | 238 | /** |
michael@0 | 239 | * Send |messageName| and |obj| to the "other side" of this message |
michael@0 | 240 | * manager. This invokes listeners who registered for |
michael@0 | 241 | * |messageName|. |
michael@0 | 242 | * |
michael@0 | 243 | * See nsIMessageListener::receiveMessage() for the format of the |
michael@0 | 244 | * data delivered to listeners. |
michael@0 | 245 | * @throws NS_ERROR_NOT_INITIALIZED if the sender is not initialized. For |
michael@0 | 246 | * example, we will throw NS_ERROR_NOT_INITIALIZED if we try to send |
michael@0 | 247 | * a message to a cross-process frame but the other process has not |
michael@0 | 248 | * yet been set up. |
michael@0 | 249 | * @throws NS_ERROR_FAILURE when the message receiver cannot be found. For |
michael@0 | 250 | * example, we will throw NS_ERROR_FAILURE if we try to send a message |
michael@0 | 251 | * to a cross-process frame whose process has crashed. |
michael@0 | 252 | */ |
michael@0 | 253 | [implicit_jscontext, optional_argc] |
michael@0 | 254 | void sendAsyncMessage([optional] in AString messageName, |
michael@0 | 255 | [optional] in jsval obj, |
michael@0 | 256 | [optional] in jsval objects, |
michael@0 | 257 | [optional] in nsIPrincipal principal); |
michael@0 | 258 | }; |
michael@0 | 259 | |
michael@0 | 260 | /** |
michael@0 | 261 | * Message "broadcasters" don't have a single "other side" that they |
michael@0 | 262 | * send messages to, but rather a set of subordinate message managers. |
michael@0 | 263 | * For example, broadcasting a message through a window message |
michael@0 | 264 | * manager will broadcast the message to all frame message managers |
michael@0 | 265 | * within its window. |
michael@0 | 266 | */ |
michael@0 | 267 | [scriptable, builtinclass, uuid(d36346b9-5d3b-497d-9c28-ffbc3e4f6d0d)] |
michael@0 | 268 | interface nsIMessageBroadcaster : nsIMessageListenerManager |
michael@0 | 269 | { |
michael@0 | 270 | /** |
michael@0 | 271 | * Like |sendAsyncMessage()|, but also broadcasts this message to |
michael@0 | 272 | * all "child" message managers of this message manager. See long |
michael@0 | 273 | * comment above for details. |
michael@0 | 274 | * |
michael@0 | 275 | * WARNING: broadcasting messages can be very expensive and leak |
michael@0 | 276 | * sensitive data. Use with extreme caution. |
michael@0 | 277 | */ |
michael@0 | 278 | [implicit_jscontext, optional_argc] |
michael@0 | 279 | void broadcastAsyncMessage([optional] in AString messageName, |
michael@0 | 280 | [optional] in jsval obj, |
michael@0 | 281 | [optional] in jsval objects); |
michael@0 | 282 | |
michael@0 | 283 | /** |
michael@0 | 284 | * Number of subordinate message managers. |
michael@0 | 285 | */ |
michael@0 | 286 | readonly attribute unsigned long childCount; |
michael@0 | 287 | |
michael@0 | 288 | /** |
michael@0 | 289 | * Return a single subordinate message manager. |
michael@0 | 290 | */ |
michael@0 | 291 | nsIMessageListenerManager getChildAt(in unsigned long aIndex); |
michael@0 | 292 | }; |
michael@0 | 293 | |
michael@0 | 294 | [scriptable, builtinclass, uuid(7fda0941-9dcc-448b-bd39-16373c5b4003)] |
michael@0 | 295 | interface nsISyncMessageSender : nsIMessageSender |
michael@0 | 296 | { |
michael@0 | 297 | /** |
michael@0 | 298 | * Like |sendAsyncMessage()|, except blocks the sender until all |
michael@0 | 299 | * listeners of the message have been invoked. Returns an array |
michael@0 | 300 | * containing return values from each listener invoked. |
michael@0 | 301 | */ |
michael@0 | 302 | [implicit_jscontext, optional_argc] |
michael@0 | 303 | jsval sendSyncMessage([optional] in AString messageName, |
michael@0 | 304 | [optional] in jsval obj, |
michael@0 | 305 | [optional] in jsval objects, |
michael@0 | 306 | [optional] in nsIPrincipal principal); |
michael@0 | 307 | |
michael@0 | 308 | /** |
michael@0 | 309 | * Like |sendSyncMessage()|, except re-entrant. New RPC messages may be |
michael@0 | 310 | * issued even if, earlier on the call stack, we are waiting for a reply |
michael@0 | 311 | * to an earlier sendRpcMessage() call. |
michael@0 | 312 | * |
michael@0 | 313 | * Both sendSyncMessage and sendRpcMessage will block until a reply is |
michael@0 | 314 | * received, but they may be temporarily interrupted to process an urgent |
michael@0 | 315 | * incoming message (such as a CPOW request). |
michael@0 | 316 | */ |
michael@0 | 317 | [implicit_jscontext, optional_argc] |
michael@0 | 318 | jsval sendRpcMessage([optional] in AString messageName, |
michael@0 | 319 | [optional] in jsval obj, |
michael@0 | 320 | [optional] in jsval objects, |
michael@0 | 321 | [optional] in nsIPrincipal principal); |
michael@0 | 322 | }; |
michael@0 | 323 | |
michael@0 | 324 | [scriptable, builtinclass, uuid(894ff2d4-39a3-4df8-9d76-8ee329975488)] |
michael@0 | 325 | interface nsIContentFrameMessageManager : nsISyncMessageSender |
michael@0 | 326 | { |
michael@0 | 327 | /** |
michael@0 | 328 | * The current top level window in the frame or null. |
michael@0 | 329 | */ |
michael@0 | 330 | readonly attribute nsIDOMWindow content; |
michael@0 | 331 | |
michael@0 | 332 | /** |
michael@0 | 333 | * The top level docshell or null. |
michael@0 | 334 | */ |
michael@0 | 335 | readonly attribute nsIDocShell docShell; |
michael@0 | 336 | |
michael@0 | 337 | /** |
michael@0 | 338 | * Print a string to stdout. |
michael@0 | 339 | */ |
michael@0 | 340 | void dump(in DOMString aStr); |
michael@0 | 341 | |
michael@0 | 342 | /** |
michael@0 | 343 | * If leak detection is enabled, print a note to the leak log that this |
michael@0 | 344 | * process will intentionally crash. |
michael@0 | 345 | */ |
michael@0 | 346 | void privateNoteIntentionalCrash(); |
michael@0 | 347 | |
michael@0 | 348 | /** |
michael@0 | 349 | * Ascii base64 data to binary data and vice versa |
michael@0 | 350 | */ |
michael@0 | 351 | DOMString atob(in DOMString aAsciiString); |
michael@0 | 352 | DOMString btoa(in DOMString aBase64Data); |
michael@0 | 353 | }; |
michael@0 | 354 | |
michael@0 | 355 | [uuid(a2325927-9c0c-437d-9215-749c79235031)] |
michael@0 | 356 | interface nsIInProcessContentFrameMessageManager : nsIContentFrameMessageManager |
michael@0 | 357 | { |
michael@0 | 358 | [notxpcom] nsIContent getOwnerContent(); |
michael@0 | 359 | }; |
michael@0 | 360 | |
michael@0 | 361 | [scriptable, builtinclass, uuid(6fb78110-45ae-11e3-8f96-0800200c9a66)] |
michael@0 | 362 | interface nsIFrameScriptLoader : nsISupports |
michael@0 | 363 | { |
michael@0 | 364 | /** |
michael@0 | 365 | * Load a script in the (remote) frame. aURL must be the absolute URL. |
michael@0 | 366 | * data: URLs are also supported. For example data:,dump("foo\n"); |
michael@0 | 367 | * If aAllowDelayedLoad is true, script will be loaded when the |
michael@0 | 368 | * remote frame becomes available. Otherwise the script will be loaded |
michael@0 | 369 | * only if the frame is already available. |
michael@0 | 370 | */ |
michael@0 | 371 | void loadFrameScript(in AString aURL, in boolean aAllowDelayedLoad, |
michael@0 | 372 | [optional] in boolean aRunInGlobalScope); |
michael@0 | 373 | |
michael@0 | 374 | /** |
michael@0 | 375 | * Removes aURL from the list of scripts which support delayed load. |
michael@0 | 376 | */ |
michael@0 | 377 | void removeDelayedFrameScript(in AString aURL); |
michael@0 | 378 | |
michael@0 | 379 | /** |
michael@0 | 380 | * Returns all delayed scripts that will be loaded once a (remote) |
michael@0 | 381 | * frame becomes available. The return value is a list of pairs |
michael@0 | 382 | * [<URL>, <WasLoadedInGlobalScope>]. |
michael@0 | 383 | */ |
michael@0 | 384 | [implicit_jscontext] |
michael@0 | 385 | jsval getDelayedFrameScripts(); |
michael@0 | 386 | }; |
michael@0 | 387 | |
michael@0 | 388 | [scriptable, builtinclass, uuid(ad57800b-ff21-4e2f-91d3-e68615ae8afe)] |
michael@0 | 389 | interface nsIProcessChecker : nsISupports |
michael@0 | 390 | { |
michael@0 | 391 | |
michael@0 | 392 | /** |
michael@0 | 393 | * Return true if the "remote" process has |aPermission|. This is |
michael@0 | 394 | * intended to be used by JS implementations of cross-process DOM |
michael@0 | 395 | * APIs, like so |
michael@0 | 396 | * |
michael@0 | 397 | * recvFooRequest: function(message) { |
michael@0 | 398 | * if (!message.target.assertPermission("foo")) { |
michael@0 | 399 | * return false; |
michael@0 | 400 | * } |
michael@0 | 401 | * // service foo request |
michael@0 | 402 | * |
michael@0 | 403 | * This interface only returns meaningful data when our content is |
michael@0 | 404 | * in a separate process. If it shares the same OS process as us, |
michael@0 | 405 | * then applying this permission check doesn't add any security, |
michael@0 | 406 | * though it doesn't hurt anything either. |
michael@0 | 407 | * |
michael@0 | 408 | * Note: If the remote content process does *not* have |aPermission|, |
michael@0 | 409 | * it will be killed as a precaution. |
michael@0 | 410 | */ |
michael@0 | 411 | boolean assertPermission(in DOMString aPermission); |
michael@0 | 412 | |
michael@0 | 413 | /** |
michael@0 | 414 | * Return true if the "remote" process has |aManifestURL|. This is |
michael@0 | 415 | * intended to be used by JS implementations of cross-process DOM |
michael@0 | 416 | * APIs, like so |
michael@0 | 417 | * |
michael@0 | 418 | * recvFooRequest: function(message) { |
michael@0 | 419 | * if (!message.target.assertContainApp("foo")) { |
michael@0 | 420 | * return false; |
michael@0 | 421 | * } |
michael@0 | 422 | * // service foo request |
michael@0 | 423 | * |
michael@0 | 424 | * This interface only returns meaningful data when our content is |
michael@0 | 425 | * in a separate process. If it shares the same OS process as us, |
michael@0 | 426 | * then applying this manifest URL check doesn't add any security, |
michael@0 | 427 | * though it doesn't hurt anything either. |
michael@0 | 428 | * |
michael@0 | 429 | * Note: If the remote content process does *not* contain |aManifestURL|, |
michael@0 | 430 | * it will be killed as a precaution. |
michael@0 | 431 | */ |
michael@0 | 432 | boolean assertContainApp(in DOMString aManifestURL); |
michael@0 | 433 | |
michael@0 | 434 | boolean assertAppHasPermission(in DOMString aPermission); |
michael@0 | 435 | |
michael@0 | 436 | /** |
michael@0 | 437 | * Return true if the "remote" process' principal has an appStatus equal to |
michael@0 | 438 | * |aStatus|. |
michael@0 | 439 | * |
michael@0 | 440 | * This interface only returns meaningful data when our content is |
michael@0 | 441 | * in a separate process. If it shares the same OS process as us, |
michael@0 | 442 | * then applying this permission check doesn't add any security, |
michael@0 | 443 | * though it doesn't hurt anything either. |
michael@0 | 444 | * |
michael@0 | 445 | * Note: If the remote content process does *not* has the |aStatus|, |
michael@0 | 446 | * it will be killed as a precaution. |
michael@0 | 447 | */ |
michael@0 | 448 | boolean assertAppHasStatus(in unsigned short aStatus); |
michael@0 | 449 | |
michael@0 | 450 | }; |