In preparation for making nsISocketTransport.securityInfo a concrete type
(nsITransportSecurityInfo), nsITLSServerConnectionInfo needs to be moved off of
securityInfo. securityCallbacks seems like a reasonable place.
Differential Revision: https://phabricator.services.mozilla.com/D154256
This implements the core of the change -- which is implementing an explicit IsTopLevel flag for
`WorkerLoadContexts`, and removing `mIsMainScript` from the loader. I've asked for some
clarification on this part of the spec from the whatwg editors, as I think this may be misnamed. It
is likely that what is meant here is `IsInitialScript` rather than `IsTopLevel` -- as there is a
note stating that this should be initialized with the agent cluster. Once this is clarified I may
update the name.
Differential Revision: https://phabricator.services.mozilla.com/D147319
Due to Shmem implementing ParamTraits, it is possible for a Shmem argument to
not be visible to the IPDL compiler as it is only serialized within an opaque
type included with `using`. If that happens, it would cause the construction of
the Shmem to fail on the other side, in a hard to diagnose manner. This changes
the logic to always allow any actor to manage shmems, to make it more in line
with the `AllocShmem` method being directly declared on IProtocol.
This specifically caused issues after this patch stack with PContent, which no
longer has any shmem arguments visible to IPDL after these changes, but still
is used as a manager for Shmems included in some messages.
Differential Revision: https://phabricator.services.mozilla.com/D151855
After the previous changes there was only one consumer left of the Shmem
version of GetSurfaceData, which could easily be changed to use BigBuffer,
removing the need for that overload.
After that consumer is removed, the interface was also simplified as the
generic logic in the implementation was no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D151854
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
Previously we would copy session storage even if we were not opening a new
window, meaning that a targeted load could re-trigger a copy. This was not
specified in the standard so is being changed to only copy when a new window is
created. In addition, the copy was moved before navigaton starts, again for
more consistency with ordering for the standard, such that things like
`javascript:` URI loads will oberve the up-to-date session storage.
Depends on D154565
Differential Revision: https://phabricator.services.mozilla.com/D154566
The `newBC` and `newDocShell` variables were potentially confusing, as they
could also be existing windows selected by named targeting or the window
provider, so they have been renamed. Some other variables were also renamed for
consistency and clarity.
Depends on D154564
Differential Revision: https://phabricator.services.mozilla.com/D154565
When opening a window with `noopener`, we will no longer inherit the
subject principal into the newly created window's initial about:blank
document, instead creating a new null principal.
This patch also makes the system/expanded principal -> null principal
translation happen earlier (it previously happened in
SetInitialPrincipalToSubject), so that it can be followed more easily
when reading the code.
Finally, the load started by nsWindowWatcher in new windows is updated
to specify `LOAD_FLAGS_DISALLOW_INHERIT_PRINCIPAL` when noopener is
specified such that the explicit about:blank load also cannot inherit
the subject principal.
This change does make it so that the global is not re-used between the
initial and loaded about:blank document, however this shouldn't be
visible due to `noopener` being specified, preventing any references to
the initial document from existing.
Noopener loads with `javascript:` URIs will be rejected early during the
load due to the mismatch between the triggering principal and the
initial about:blank document's principal.
Depends on D154563
Differential Revision: https://phabricator.services.mozilla.com/D154564
Previously we would pull this information frequently from the subject
principal, which is unreliable. With this new approach, we more explicitly pass
the principals around as-needed into where they're going to be used.
Some assertions about the subject principal were introduced to ensure that
assumptions made about chrome windows and the system principal are not
incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D154563
Uri.host throws when scheme is moz-proxy://
This leads to a series of bugs on about:logins when creating or editing moz-proxy URLs.
This patch is supposed to close bug 1559205, bug 1611093 and bug 1748828.
Differential Revision: https://phabricator.services.mozilla.com/D154925
Adds event "GeckoView:Test:NewTab”, which allow testers to create tabs.
`GeckoViewTestUtils.jsm` sends the event from the JavaScript side for
use in testing.
A `ServiceWorkerDelegate` is required to be set for the
`GeckoRuntime` to use these events, which was setup on the test
runner.
Differential Revision: https://phabricator.services.mozilla.com/D152891
The ColorSchemeMode::Preferred change doesn't make a difference (that
is, always use the preferred one), since when we only propagate from
top's embedder the embedder is chrome, which always has the preferred
color-scheme.
Differential Revision: https://phabricator.services.mozilla.com/D154931
Cleanup, optional. Repeating the same work on the NetWorkLoaderHandler as on the WorkerScriptLoader.
Previously, this was considered "safe" because the assumption is that the NetworkLoadHandler is
shorter lived than the WorkerScriptLoader. Rather than assuming this, if we end up in a situation
where this does out-live the WorkerScriptLoader, then we will end up leaking.
Differential Revision: https://phabricator.services.mozilla.com/D154384
Cleanup, optional. It seems strange to have two ways to access the WorkerPrivate, and
ThreadSafeWorkerRef seems like the more reasonable choice.
Differential Revision: https://phabricator.services.mozilla.com/D154383
This addresses part of the issue, by holding a strong ref until we shutdown, so that we do not end
up in a situation where the worker closes before we finish cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D154381