
Refactor PermissionRequestDescription to hold PermissionDescriptorPtr. Permissions with options can no longer be represented by a simple PermissionType enum value, hence future infrastructure refactorings to enable them will pass around PermissionDescriptorPtrs instead of mapping PermissionDescriptorPts to PermissionTypes. To reduce the complexity of this CL, it limits the scope of the refactoring to PermissionRequestDescription, its creations and usages and uses utility mapping functions to map PermissionRequestDescriptionPtr usages of this object to the PermissionTypes. I.e. it does not yet modify the infrastructure itself yet to rely on PermissionRequestDescriptorPtr. Since all ContentSetting permission types currently map to exactly one PermissionDescriptorPtr and vice versa, the mapping for all content setting permission types is unique and can rely on these mapping utility functions. Permissions that want to make use of permission options in the future, will create the correct PermissionRequestDescriptorPtr instead of relying on the current mapping functions. refactoring. We need to add mapping functions to reduce the scope of this CL and avoid having to make all changes at once. These mapping functions will not be necessary in fuchsia, as the infrastructure will move to fully relying on a different type. Bug: 405943540, 393053278 Fuchsia-Binary-Size: Increase is temporary. This CL is part of a large Change-Id: I9d6e3e71385749787a973a61e41ce130665c860d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6387077 Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Nate Fischer <ntfschr@chromium.org> Commit-Queue: Florian Jacky <fjacky@chromium.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@chromium.org> Cr-Commit-Position: refs/heads/main@{#1443356}
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:
./common
contains code shared by both WebEngine and Runners../runners
contains implementations of Fuchsiasys.runner
../runners/cast
Enables the Fuchsia system to launch Cast applications.
./shell
contains WebEngineShell, a simple wrapper for launching URLs in WebEngine from the command line../webengine
contains the WebEngine implementation. WebEngine is an implementation offuchsia.web
that enables Fuchsia Components to render web content using Chrome's Content layer../webinstance_host
contains 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_tests
make use of the//fuchsia_web/webengine:web_engine
component. 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.