475dbba005
On collections page, display a preview of local images. Clicking on preview takes user to a new sub-page that displays all local images. More work on error and loading behavior is necessary to match UX mock. Render local images in trusted side because they are already data urls. This reduces code complexity and memory overhead of copying thumbnail previews across an iframe. Share styles between untrusted and trusted so that image grids look the same in both cases. BUG=b/189968254 TEST=browser_tests --gtest_filter="PersonalizationApp*" Cq-Include-Trybots: luci.chrome.try:linux-chromeos-chrome Change-Id: I36635c8f0567d0a08ae10566c197d5ba55cc2602 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2957198 Commit-Queue: Jeffrey Young <cowmoo@chromium.org> Reviewed-by: Xiaohui Chen <xiaohuic@chromium.org> Cr-Commit-Position: refs/heads/master@{#893091}
Chrome OS
This directory contains low-level support for Chrome running on Chrome OS.
The Lacros project is in the process of extracting the browser-functionality into a separate binary. This introduces the following terminology and rules:
- ash-chrome: The new name of the legacy "chrome" binary. It contains system UI and the current/legacy web browser. Code that is only used by ash-chrome should eventually be moved to //ash, have an _ash suffix in the filename, or have a (grand-)parent directory named /ash/.
- lacros-chrome: The name of the new, standalone web-browser binary. Code that is only used by lacros-chrome should have a _lacros suffix in the filename, or have a (grand-)parent directory named /lacros/.
- crosapi: The term "crosapi" is short for ChromeOS API. Ash-chrome implements the API, and lacros-chrome is the only consumer.
- chromeos: The term "chromeos" refers to code that is shared by binaries targeting the chromeos platform or using the chromeos toolchain. Code that is shared by ash-chrome and lacros-chrome should have a _chromeos suffix in the filename, or have a (grand-)parent directory named /chromeos/.
- Exception: The exception to the rule is //chrome/browser/chromeos. Following existing conventions in //chrome, the directory should refer to lacros-chrome. However, this would involve a massive and otherwise unnecessary refactor. //chrome/browser/chromeos will continue to contain code that is only used by ash-chrome. //chrome/browser/lacros will contain code used only by lacros-chrome. See this document for more details.
Many subdirectories contain Chrome-style C++ wrappers around operating system components.
For example, //chromeos/dbus contains wrappers around the D-Bus interfaces to system daemons like the network configuration manager (shill). Most other directories contain low-level utility code. For example, //chromeos/disks has utilities for mounting and unmounting disk volumes.
There are two exceptions:
-
//chromeos/services contains mojo services that were not considered sufficiently general to live in top-level //services. For example //chromeos/services/secure_channel bootstraps a secure communications channel to an Android phone over Bluetooth, enabling multi-device features like instant tethering.
-
//chromeos/components contains C++ components that were not considered sufficiently general to live in top-level //components.
Note, //chromeos does not contain any user-facing UI code, and hence it has "-ui" in its DEPS. The contents of //chromeos should also not depend on //chrome or //content.