We pay down some tech debt by adding a browser-side
`PermissionsPolicy` check for the
`blink::mojom::PermissionsPolicyFeature::kSharedStorage` feature
in the cases where the initial check was done by the renderer.
For the iframe navigation case, however, since the initial
permissions policy check for shared storage writing from an iframe
navigation request already occurs in the browser process in
`NavigationRequest`, it's not absolutely necessary to do a double
check, and so if we are unable to perform one due to not being able
to obtain the parent policy, we skip the check and proceed with the
operation(s). Whereas, in non-navigation-initiated cases, if we are
unable to perform the check, we drop any operation(s).
While we're at it, we pass in the `NavigationOrDocumentHandle` to
`SharedStorageHeaderObserver::HeaderReceived()` instead of the
`RenderFrameHost`, and add a method
`NavigationOrDocumentHandle::GetTopFrameOrigin()`, to try to avoid
having to create a new opaque origin for the user profile preferences
check in the case when a `RenderFrameHost` is not available to help us
access the main frame's last committed origin.
We also add a couple of metrics related to the above.
Note that in "SharedStorageHeaderObserverTest", we swap out the
`ContentBrowserClient` for a derived `MockContentBrowserClient`
instance to control the return value of
`MockContentBrowserClient::IsSharedStorageAllowed()`.
Bug: 1434529,1218540
Change-Id: I7020626511215bbfc1972e6a3fddef5432b95cd1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4944272
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Yao Xiao <yaoxia@chromium.org>
Commit-Queue: Cammie Smith Barnes <cammie@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1239898}
Since SSLManager is bound to NavigationController not WebContents,
it should get the associated navigation controller instead of the
primary navigation controller. Therefore this CL passes
NavigationOrDocumentHandle to SSLManager::OnSSLCertificateError, so
that SSLManager plumbs the correct navigation controller.
Bug: 1284189
Change-Id: Iaca620f12798e7f99312d22f9c72e1a6942f919b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3366165
Reviewed-by: Adam Langley <agl@chromium.org>
Reviewed-by: Kevin McNee <mcnee@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Yeunjoo Choi <ychoi@igalia.com>
Cr-Commit-Position: refs/heads/main@{#990269}
In the current code, URLLoaderNetworkContext in StoragePartitionImpl
is created for a document, service worker, or a navigation. For a
document, it's tracking with RenderFrameHostImpl and, for navigation,
it's tracking with a FrameTreeNode ID.
It has three different incompatible uses of Routing ID for navigation
request, a frame, or service worker.
Here, we're also using the FrameTreeNode id as a proxy, but it's not
ideal as the navigation can be canceled and another navigation can
start in the same FrameTreeNode.
This CL introduces NavigationOrDocumentHandle that has a weak ptr
to RenderFrameHostImpl or NavigationRequest and
URLLoaderNetworkContext is created with it.
It includes several changes,
- it introduces NavigationOrDocumentHandle to support a seamless
transfer from a navigation to a committed document. It has
RenderFrameHost or NavigationRequest for the network context.
If the context is created for a navigation request, its
RenderFrameHost member is populated when the navigation is
committed.
- it incorporates two CancelIfPrerendering() helpers, one with
`frame_tree_node_id` and the other with `render_frame_host_id`,
by taking NavigationOrDocumentHandle.
- RenderFrameHost and NavigationRequest create
NavigationOrDocumentHandle and URLLoaderNetworkContext refers to
them when they are created.
This is a follow-up CL of https://crrev.com/c/3261291
Bug: 1241836, 1239554
Change-Id: I2c6abe17436c276c460e1721fc8b1ef2b38a5ae0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3341866
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Julie Jeongeun Kim <jkim@igalia.com>
Cr-Commit-Position: refs/heads/main@{#988227}