2455e70001
blink::WebURLRequest is used for the argument of
URLLoaderThrottleProvider::CreateThrottles() method after [1]. But we
are planing to call this method from the background thread where we
don't use blink::WebURLRequest [2]. Also we are planing to deprecate
blink::WebURLRequest, and planing to use network::ResourceRequest
instead [3].
So this CL changes the argument type of CreateThrottles() from
blink::WebURLRequest to network::ResourceRequest.
A network::ResourceRequest is created in ResourceLoader::Start(). So we
pass the reference of the structure through ResourceFetcher::
CreateURLLoader().
In frames:
ResourceLoader::Start()
-> ResourceFetcher::CreateURLLoader()
-> LoaderFactoryForFrame::CreateURLLoader()
|-> URLLoaderThrottleProvider::CreateThrottles()
|-> ServiceWorkerNetworkProviderForFrame::
| GetSubresourceLoaderFactory()
|-> URLLoaderFactory::CreateURLLoader()
In workers:
ResourceLoader::Start()
-> ResourceFetcher::CreateURLLoader()
-> LoaderFactoryForWorker::CreateURLLoader()
|-> WebWorkerFetchContext::CreateThrottles()
| -> WebServiceWorkerFetchContextImpl::CreateThrottles() or
| DedicatedOrSharedWorkerFetchContextImpl::CreateThrottles()
| -> URLLoaderThrottleProvider::CreateThrottles()
|-> URLLoaderFactory::CreateURLLoader()
mojom::blink::RequestContextType in blink::WebURLRequest is checked in
the code path. But this type member is not in network::ResourceRequest.
network::ResourceRequest has a network::mojom::RequestDestination
member. And some of these checks of mojom::blink::RequestContextType can
be safely converted to network::mojom::RequestDestination without any
behavior change. But the check in ResourceFetcher::CreateURLLoader()
needs the mojom::blink::RequestContextType. Also we need to pass
`service_worker_race_network_request_token` to
LoaderFactoryForWorker::CreateURLLoader(), and
`is_from_origin_dirty_style_sheet` flag to
ServiceWorkerNetworkProviderForFrame::GetSubresourceLoaderFactory().
So this CL adds these three arguments to CreateURLLoader() methods.
[1]: https://crrev.com/c/994152
[2]: https://crrev.com/c/5113665
[3]: https://groups.google.com/a/chromium.org/forum/#!topic/platform-architecture-dev/ntSzerId4gw
Bug: 1379780
Change-Id: I6e0a987d779b1fb428a4b27b813b3f53f2d1d781
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5121813
Reviewed-by: Erik Chen <erikchen@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Sean Topping <seantopping@chromium.org>
Reviewed-by: Richard (Torne) Coles <torne@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: David Song <wintermelons@google.com>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1245656}
fuchsia.web - Fuchsia WebEngine and Runners
This directory contains code related to the
fuchsia.web FIDL API.
Specifically, it contains the implementation of Fuchsia WebEngine and code
related to it, including the Runners that use it. Code in this
directory must not be used outside it and its subdirectories.
General information about Chromium on Fuchsia is here.
[TOC]
Code organization
Each of the following subdirectories contain code for a specific Fuchsia service:
./commoncontains code shared by both WebEngine and Runners../runnerscontains implementations of Fuchsiasys.runner../runners/castEnables the Fuchsia system to launch Cast applications.
./shellcontains WebEngineShell, a simple wrapper for launching URLs in WebEngine from the command line../webenginecontains the WebEngine implementation. WebEngine is an implementation offuchsia.webthat enables Fuchsia Components to render web content using Chrome's Content layer../webinstance_hostcontains code for WebEngine clients to directly instantiate a WebInstance Component (web_instance.cm) using the WebEngine package.
Test code
There are 3 major types of tests within this directory:
- Unit tests: Exercise a single class in isolation, allowing full control over the external environment of this class.
- Browser tests: Spawn a full browser process and its child processes. The test code is run inside the browser process, allowing for full access to the browser code - but not other processes.
- Integration tests: Exercise the published FIDL API of a Fuchsia Component. For
instance,
//fuchsia_web/webengine:web_engine_integration_testsmake use of the//fuchsia_web/webengine:web_enginecomponent. The test code runs in a separate process in a separate Fuchsia Component, allowing only access to the published API of the component under test.
Integration tests are more resource-intensive than browser tests, which are in turn more expensive than unit tests. Therefore, when writing new tests, it is preferred to write unit tests over browser tests over integration tests.
As a general rule, test-only code should live in the same directory as the code
under test with an explicit file name, either fake_*, test_*,
*_unittest.cc, *_ browsertest.cc or *_integration_test.cc.
Test code that is shared across Components should live in a dedicated ``test
directory. For example, the //fuchsia_web/webengine/test directory, which
contains code shared by all browser tests, and
//fuchsia_web/common/test, which contains code shared by tests for both
WebEngine and Runners.