Adding upstream version 86.0.1.upstream/86.0.1upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 102 insertions, 0 deletions

diff --git a/dom/localstorage/PBackgroundLSRequest.ipdl b/dom/localstorage/PBackgroundLSRequest.ipdl
new file mode 100644
index 0000000000..4985c09d0f
--- /dev/null
+++ b/dom/localstorage/PBackgroundLSRequest.ipdl
@@ -0,0 +1,102 @@
+/* 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/. */
+
+include protocol PBackground;
+
+using struct mozilla::null_t from "mozilla/ipc/IPCCore.h";
+
+namespace mozilla {
+namespace dom {
+
+struct LSRequestPreloadDatastoreResponse
+{
+};
+
+struct LSRequestPrepareDatastoreResponse
+{
+  uint64_t datastoreId;
+};
+
+struct LSRequestPrepareObserverResponse
+{
+  uint64_t observerId;
+};
+
+/**
+ * Discriminated union which can contain an error code (`nsresult`) or
+ * particular request response.
+ */
+union LSRequestResponse
+{
+  nsresult;
+  LSRequestPreloadDatastoreResponse;
+  LSRequestPrepareDatastoreResponse;
+  LSRequestPrepareObserverResponse;
+};
+
+/**
+ * An asynchronous protocol for issuing requests that are used in a synchronous
+ * fashion by LocalStorage via LSObject's RequestHelper mechanism.  This differs
+ * from LSSimpleRequest which is implemented and used asynchronously.
+ *
+ * See `PBackgroundLSSharedTypes.ipdlh` for more on the request types, the
+ * response types above for their corresponding responses, and `RequestHelper`
+ * for more on the usage and lifecycle of this mechanism.
+ */
+protocol PBackgroundLSRequest
+{
+  manager PBackground;
+
+parent:
+  // The Cancel message is used to avoid a possible dead lock caused by a CPOW
+  // sending a synchronous message from the main thread in the chrome process
+  // to the main thread in the content process at the time we are blocking
+  // the main thread in the content process to handle a request.
+  // We use the PBackground thread on the parent side to handle requests, but
+  // sometimes we need to get information from principals and that's currently
+  // only possible on the main thread. So if the main thread in the chrome
+  // process is blocked by a CPOW operation, our request must wait for the CPOW
+  // operation to complete. However the CPOW operation can't complete either
+  // because we are blocking the main thread in the content process.
+  // The dead lock is prevented by canceling our nested event loop in the
+  // content process when we receive a synchronous IPC message from the parent.
+  //
+  // Note that cancellation isn't instantaneous.  It's just an asynchronous flow
+  // that definitely doesn't involve the main thread in the parent process, so
+  // we're guaranteed to unblock the main-thread in the content process and
+  // allow the sync IPC to make progress.  When Cancel() is received by the
+  // parent, it will Send__delete__.  The child will either send Cancel or
+  // Finish, but not both.
+  async Cancel();
+
+  /**
+   * Sent by the child in response to Ready, requesting that __delete__ be sent
+   * with the result.  The child will either send Finish or Cancel, but not
+   * both.  No further message will be sent from the child after invoking one.
+   */
+  async Finish();
+
+child:
+  /**
+   * The deletion is sent with the result of the request directly in response to
+   * either Cancel or Finish.
+   */
+  async __delete__(LSRequestResponse response);
+
+  /**
+   * Sent by the parent when it has completed whatever async stuff it needs to
+   * do and is ready to send the results.  It then awaits the Finish() call to
+   * send the results.  This may seem redundant, but it's not.  If the
+   * __delete__ was sent directly, it's possible there could be a race where
+   * Cancel() would be received by the parent after it had already sent
+   * __delete__.  (Which may no longer be fatal thanks to improvements to the
+   * IPC layer, but it would still lead to warnings, etc.  And we don't
+   * expect PBackground to be highly contended nor the RemoteLazyInputStream
+   * thread.)
+   */
+  async Ready();
+};
+
+} // namespace dom
+} // namespace mozilla