From c30a6232df03e1efbd9f3b226777b07e087a1122 Mon Sep 17 00:00:00 2001 From: Allan Sandfeld Jensen Date: Mon, 12 Oct 2020 14:27:29 +0200 Subject: BASELINE: Update Chromium to 85.0.4183.140 Change-Id: Iaa42f4680837c57725b1344f108c0196741f6057 Reviewed-by: Allan Sandfeld Jensen --- chromium/docs/OWNERS | 5 + chromium/docs/accessibility/autoclick.md | 30 +- chromium/docs/accessibility/brltty.md | 32 +- chromium/docs/accessibility/patts.md | 4 +- chromium/docs/accessibility/tts.md | 5 +- chromium/docs/adding_to_third_party.md | 4 +- chromium/docs/chromedriver_status.md | 1 + chromium/docs/clang_format.md | 66 +- chromium/docs/clang_sheriffing.md | 7 + chromium/docs/clang_tidy.md | 63 +- chromium/docs/clangd.md | 15 +- chromium/docs/code_reviews.md | 9 +- chromium/docs/commit_checklist.md | 115 +- chromium/docs/contributing.md | 4 + chromium/docs/design/sandbox.md | 8 + chromium/docs/enterprise/add_new_policy.md | 55 +- chromium/docs/enterprise/extension_query.py | 43 +- chromium/docs/enterprise/extension_query_py2.py | 38 +- chromium/docs/fuchsia_build_instructions.md | 2 +- chromium/docs/fuchsia_gardening.md | 2 + chromium/docs/gpu/gpu_testing.md | 17 +- chromium/docs/gpu/gpu_testing_bot_details.md | 53 +- chromium/docs/how_cc_works.md | 12 +- chromium/docs/ios/build_instructions.md | 5 + chromium/docs/ios/xcode_tips.md | 7 +- chromium/docs/linux/debugging.md | 9 +- chromium/docs/mac/triage.md | 2 +- .../media/gpu/video_decoder_perf_test_usage.md | 4 + .../docs/media/gpu/video_decoder_test_usage.md | 4 + .../docs/media/gpu/video_encoder_test_usage.md | 73 ++ chromium/docs/mojo_and_services.md | 14 +- .../docs/navigation-request-navigation-state.gv | 17 + .../docs/navigation-request-navigation-state.png | Bin 0 -> 160244 bytes chromium/docs/ozone_overview.md | 3 +- chromium/docs/privacy_budget_code_locations.md | 68 + chromium/docs/profiling.md | 2 +- chromium/docs/render-frame-host-lifecycle-state.gv | 11 + .../docs/render-frame-host-lifecycle-state.png | Bin 0 -> 45773 bytes chromium/docs/security/OWNERS | 1 + chromium/docs/security/compromised-renderers.md | 29 +- chromium/docs/security/sheriff.md | 11 +- .../docs/security/side-channel-threat-model.md | 28 +- chromium/docs/session_history.md | 125 ++ chromium/docs/sheriff.md | 27 +- .../how_to_disable_a_story.md | 8 +- chromium/docs/speed/good_toplevel_metrics.md | 31 +- .../docs/speed/graphics_metrics_definitions.md | 121 ++ chromium/docs/testing/android_test_instructions.md | 4 +- .../testing/rendering_representative_perf_tests.md | 79 +- chromium/docs/testing/web_tests.md | 57 +- .../docs/testing/web_tests_in_content_shell.md | 13 +- chromium/docs/threading_and_tasks.md | 87 ++ chromium/docs/ui/index.md | 7 + chromium/docs/ui/learn/bestpractices/colors.md | 59 +- chromium/docs/ui/learn/bestpractices/layout.md | 1350 ++++++++++++++++++++ chromium/docs/ui/learn/bestpractices/ownership.md | 28 +- chromium/docs/ui/learn/index.md | 1 + chromium/docs/ui/navbar.md | 9 +- chromium/docs/ui/views/overview.md | 9 +- chromium/docs/updating_clang.md | 67 +- chromium/docs/vscode.md | 15 +- chromium/docs/webui_explainer.md | 2 +- chromium/docs/windows_build_instructions.md | 5 + chromium/docs/workflow/debugging-with-swarming.md | 6 +- 64 files changed, 2611 insertions(+), 377 deletions(-) create mode 100644 chromium/docs/media/gpu/video_encoder_test_usage.md create mode 100644 chromium/docs/navigation-request-navigation-state.gv create mode 100644 chromium/docs/navigation-request-navigation-state.png create mode 100644 chromium/docs/privacy_budget_code_locations.md create mode 100644 chromium/docs/render-frame-host-lifecycle-state.gv create mode 100644 chromium/docs/render-frame-host-lifecycle-state.png create mode 100644 chromium/docs/session_history.md create mode 100644 chromium/docs/speed/graphics_metrics_definitions.md create mode 100644 chromium/docs/ui/learn/bestpractices/layout.md (limited to 'chromium/docs') diff --git a/chromium/docs/OWNERS b/chromium/docs/OWNERS index 94ca8dea854..f75e5460ad5 100644 --- a/chromium/docs/OWNERS +++ b/chromium/docs/OWNERS @@ -1,2 +1,7 @@ * + +# build@ isn't really the right component for this, but it'll +# do until we create a component for documentation. + +# TEAM: build@chromium.org # COMPONENT: Build diff --git a/chromium/docs/accessibility/autoclick.md b/chromium/docs/accessibility/autoclick.md index dd088bb88ec..fb1783983a3 100644 --- a/chromium/docs/accessibility/autoclick.md +++ b/chromium/docs/accessibility/autoclick.md @@ -46,7 +46,7 @@ ash/autoclick/ ash/system/accessibility/autoclick* - A component extension to provide Accessibility tree information, in -chrome/browser/resources/chromeos/accessibility/autoclick/ +chrome/browser/resources/chromeos/accessibility/accessibility_common/ In addition, there are settings for automatic clicks in chrome/browser/resources/settings/a11y_page/manage_a11y_page.* @@ -64,15 +64,15 @@ out/Release/browser_tests --gtest_filter=”Autoclick*” ### Debugging Developers can add log lines to any of the autoclick C++ files and see output -in the console. To debug the Autoclick extension, the easiest way is from an -external browser. Start Chrome OS on Linux with this command-line flag: +in the console. To debug the Accessibility Common extension, the easiest way is +from an external browser. Start Chrome OS on Linux with this command-line flag: ``` out/Release/chrome --remote-debugging-port=9222 ``` Now open http://localhost:9222 in a separate instance of the browser, and debug -the Autoclick extension background page from there. +the Accessibility Common extension background page from there. ## How it works @@ -132,16 +132,16 @@ may dwell anywhere on the screen to change the scroll location. When the scroll location is changed, the AutoclickController will request the -bounds of the nearest scrollable view from the Autoclick component extension -via the AccessibilityPrivate API. The Autoclick component extension has access -to accessibility tree information, and using a HitTest is able to find the view -at the scroll location, then walks up the tree to find the first view which can -scroll, or stops at the nearest window or dialog bounds. This logic takes place -in autoclick.js, onAutomationHitTestResult_. When the scrolling location is -found, the bounds of the scrollable area are highlighted with a focus ring. -In addition, the bounds are sent back through the AccessibilityPrivate API, -routed to the AutoclickController, which passes it via the -AutoclickMenuBubbleController to the AutoclickScrollBubbleController, which +bounds of the nearest scrollable view from the Accessibility Common extension +via the AccessibilityPrivate API. The Accessibility Common component extension +has access to accessibility tree information, and using a HitTest is able to +find the view at the scroll location, then walks up the tree to find the first +view which can scroll, or stops at the nearest window or dialog bounds. This +logic takes place in autoclick.js, onAutomationHitTestResult_. When the +scrolling location is found, the bounds of the scrollable area are highlighted +with a focus ring. In addition, the bounds are sent back through the +AccessibilityPrivate API, routed to the AutoclickController, which passes it via +the AutoclickMenuBubbleController to the AutoclickScrollBubbleController, which does layout accordingly. ### Bubble Menus: interface and positioning @@ -175,7 +175,7 @@ UI. The scroll bubble starts out anchored to the automatic clicks bubble menu, but if the user selects a new scroll point it will move. When a scroll point is -selected, if the scrollable region found by the Autoclick component extension +selected, if the scrollable region found by the Accessibility Common extension is large enough, the scroll bubble will be anchored near the scroll point itself, similarly to the way the context menu is anchored near the cursor on a right click. When the scrollable region is small, the scroll bubble will be diff --git a/chromium/docs/accessibility/brltty.md b/chromium/docs/accessibility/brltty.md index 32c95be70b4..e05f1d7ad73 100644 --- a/chromium/docs/accessibility/brltty.md +++ b/chromium/docs/accessibility/brltty.md @@ -65,8 +65,8 @@ To upload a change, use repo, something like this: ``` repo start . git commit -a - Bug:chromium:12345 - Test:Write what you tested here + Bug: chromium:12345 + Test: Write what you tested here repo upload . ``` @@ -119,6 +119,11 @@ Next, you will need to uprev the ebuild. Do this by renaming all files from the E.g. Brltty-5.4.ebuild -> brltty-5.6.ebuild +Start a build with your changes by doing + +emerge brltty +(or emerge{$BOARD} brltty). + Note: Manifest has various checksums computed based on the release you uploaded to GCS. Each of these will need to be replaced/updated. This should be enough to kick off a build. It is likely patches won’t apply cleanly. @@ -141,6 +146,29 @@ commits to the file containing the conflict then understanding the history since the last release. If the patch is already upstreamed, you can remove it from the Chrome OS repo. +### Chrome side changes + +Chrome communicates with brltty using libbrlapi. +libbrlapi resides at //third_party/libbrlapi. + +Chrome loads this library dynamically and hard-codes the expected version of the api so in +chrome/browser/extensions/api/braille_display_private/braille_controller_brlapi.cc + +which should match up with the header in +third_party/libbrlapi/brlapi.h. + +During uppreving, if brltty increments its api version, it will be necessary to update the header for libbrlapi, as well as incrementing the supported api version of the libbrlapi shared object. + +First, grab the generated header from your Chrome OS build above. +cp /build/$BOARD/usr/include/brlapi.h /third_party/libbrlapi/brlapi.h + +This header contains the specific socket path for Chrome OS which differs from brltty defaults. + +Next, ensure the version in +chrome/browser/extensions/api/braille_display_private/braille_controller_brlapi.cc + +matches the one in the new brltty. + ### Testing Firstly, try to test against brltty on linux. This involves building brltty at diff --git a/chromium/docs/accessibility/patts.md b/chromium/docs/accessibility/patts.md index 637be788539..719d97c238a 100644 --- a/chromium/docs/accessibility/patts.md +++ b/chromium/docs/accessibility/patts.md @@ -101,8 +101,8 @@ To upload the change, use repo upload, something like this: ``` git commit -a - Bug:chromium:12345 - Test:Write what you tested here + Bug: chromium:12345 + Test: Write what you tested here repo upload . ``` diff --git a/chromium/docs/accessibility/tts.md b/chromium/docs/accessibility/tts.md index 353479b54ad..3cbe949e450 100644 --- a/chromium/docs/accessibility/tts.md +++ b/chromium/docs/accessibility/tts.md @@ -41,8 +41,7 @@ platform. (in content/) processes utterances and sends them to the correct output engine. - The [TtsControllerDelegateImpl](https://cs.chromium.org/chromium/src/chrome/browser/speech/tts_controller_delegate_impl.h) -(in chrome/) provides chrome-specific functionality, including making use of -user prefs in Chrome OS. +(in chrome/) provides chrome OS specific functionality. ### Output @@ -76,4 +75,4 @@ user prefs in Chrome OS. - Fuzzer - In content_unittests, content/browser/speech/tts_platform_fuzzer.cc - (currently Windows only). \ No newline at end of file + (currently Windows only). diff --git a/chromium/docs/adding_to_third_party.md b/chromium/docs/adding_to_third_party.md index 72f32f67a5f..8bbb278cd47 100644 --- a/chromium/docs/adding_to_third_party.md +++ b/chromium/docs/adding_to_third_party.md @@ -175,7 +175,9 @@ Non-Googlers can email one of the people in licensing matters. These reviewers may not be able to +1 a change so look for verbal approval in the comments. (This list does not receive or deliver email, so only use it as a reviewer, not for other communication. Internally, - see cl/221704656 for details about how this is configured.) + see [cl/221704656](https://cl/221704656) for details about how + this is configured.). If you have questions about the third-party process, + ask one of the [//third_party/OWNERS](../third_party/OWNERS) instead. * Lastly, if all other steps are complete, get a positive code review from a member of [//third_party/OWNERS](../third_party/OWNERS) to land the change. diff --git a/chromium/docs/chromedriver_status.md b/chromium/docs/chromedriver_status.md index ccdc14ffe0c..c94b8b187e9 100644 --- a/chromium/docs/chromedriver_status.md +++ b/chromium/docs/chromedriver_status.md @@ -59,3 +59,4 @@ Below is a list of all WebDriver commands and their current support in ChromeDri | POST | /session/{session id}/alert/text | Send Alert Text | Complete | | GET | /session/{session id}/screenshot | Take Screenshot | Complete | | GET | /session/{session id}/element/{element id}/screenshot | Take Element Screenshot | Complete | +| POST | /session/{session id}/print | Print Page | Partially Complete(available for Headless) | [3481](https://bugs.chromium.org/p/chromedriver/issues/detail?id=3481) diff --git a/chromium/docs/clang_format.md b/chromium/docs/clang_format.md index 1fa34d076fc..c14eb33ae0d 100644 --- a/chromium/docs/clang_format.md +++ b/chromium/docs/clang_format.md @@ -1,5 +1,7 @@ # Using clang-format on Chromium C++ Code +[TOC] + *** note NOTE: This page does not apply to the Chromium OS project. See [Chromium Issue 878506](https://bugs.chromium.org/p/chromium/issues/detail?id=878506#c10) @@ -9,15 +11,16 @@ for updates. ## Easiest usage, from the command line To automatically format a pending patch according to -[Chromium style](https://www.chromium.org/developers/coding-style), from -the command line, simply run: ``` git cl format ``` This should work on all -platforms _(yes, even Windows)_ without any set up or configuration: the tool -comes with your checkout. Like other `git-cl` commands, this operates on a diff -relative to the upstream branch. Only the lines that you've already touched in -your patch will be reformatted. You can commit your changes to your git branch -and then run `git cl format`, after which `git diff` will show you what -clang-format changed. Alternatively, you can run `git cl format` with your -changes uncommitted, and then commit your now-formatted code. +[Chromium style](https://www.chromium.org/developers/coding-style), run: +``` git cl format ``` from the command line. This should work on all platforms +without any extra set up: the tool is integrated with depot_tools and the +Chromium checkout. + +Like other `git-cl` commands, this operates on a diff relative to the upstream +branch. Only the lines that changed in a CL will be reformatted. To see what +clang-format would choose, commit any local changes and then run `git cl +format` followed by `git diff`. Alternatively, run `git cl format` and commit +the now-formatted code. ## Editor integrations @@ -44,27 +47,36 @@ For further guidance on editor integration, see these specific pages: * For vim, `:so tools/vim/clang-format.vim` and then hit cmd-shift-i (mac) ctrl-shift-i (elsewhere) to indent the current line or current selection. -## Are robots taking over my freedom to choose where newlines go? - -No. For the project as a whole, using clang-format is just one optional way to -format your code. While it will produce style-guide conformant code, other -formattings would also satisfy the style guide, and all are okay. - -Having said that, many clang-format converts have found that relying on a tool -saves both them and their reviewers time. The saved time can then be used to -discover functional defects in their patch, to address style/readability -concerns whose resolution can't be automated, or to do something else that -matters. - -In directories where most contributors have already adopted clang-format, and -code is already consistent with what clang-format would produce, some teams -intend to experiment with standardizing on clang-format. When these local -standards apply, it will be enforced by a PRESUBMIT.py check. - ## Reporting problems If clang-format is broken, or produces badly formatted code, please file a -[bug]. Assign it to thakis@chromium.org who will route it upstream. +[bug]. Assign it to thakis@chromium.org or dcheng@chromium.org, who will route +it upstream. [bug]: https://code.google.com/p/chromium/issues/entry?comment=clang-format%20produced%20code%20that%20(choose%20all%20that%20apply):%20%0A-%20Doesn%27t%20match%20Chromium%20style%0A-%20Doesn%27t%20match%20blink%20style%0A-%20Riles%20my%20finely%20honed%20stylistic%20dander%0A-%20No%20sane%20human%20would%20ever%20choose%0A%0AHere%27s%20the%20code%20before%20formatting:%0A%0A%0AHere%27s%20the%20code%20after%20formatting:%0A%0A%0AHere%27s%20how%20it%20ought%20to%20look:%0A%0A%0ACode%20review%20link%20for%20full%20files/context:&summary=clang-format%20quality%20problem&cc=thakis@chromium.org&labels=Type-Bug,Build-Tools,OS-?,clang-format + +## Are robots taking over my freedom to choose where newlines go? + +Mostly. At upload time, a presubmit check warns if a CL is not clang-formatted, +but this is a non-blocking warning, and the CL may still be submitted. Even so, +try to prefer clang-format's output when possible: + +- While clang-format does not necessarily format code the exact same way a human + might choose, it produces style-conformat code by design. This can allow + development and review time to be focused on discovering functional defects, + addressing readability/understandability concerns that can't be automatically + fixed by tooling, et cetera. +- Continually fighting the tooling is a losing battle. Most Chromium developers + use clang-format. Large-scale changes will simply run `git cl format` once to + avoid having to deal with the particulars of formatting. Over time, this will + likely undo any carefully-curated manual formatting of the affected lines. + +There is one notable exception where clang-format is often disabled: large +tables of data are often surrounded by `// clang-format off` and `// +clang-format on`. Try to use this option sparingly, as widespread usage makes +tool-assisted refactoring more difficult. + +Again, if clang-format produces something odd, please err on the side of +[reporting an issue](#Reporting-problems): bugs that aren't reported can't be +fixed. diff --git a/chromium/docs/clang_sheriffing.md b/chromium/docs/clang_sheriffing.md index 264a4c595ff..242e8d1c24b 100644 --- a/chromium/docs/clang_sheriffing.md +++ b/chromium/docs/clang_sheriffing.md @@ -17,6 +17,13 @@ document describes some of the processes and techniques for doing that. https://sheriff-o-matic.appspot.com/chromium.clang is the sheriff-o-matic view of that waterfall, which can be easier to work with. +In addition to the waterfall, make sure +[dry run attempts at updating clang](https://chromium-review.googlesource.com/q/owner:thakis%2540chromium.org+%2522roll+clang%2522) +are green. As part of the Clang release process we run upstream LLVM tests. +Ideally these tests are covered by upstream LLVM bots and breakages are +quickly noticed and fixed by the original author of a breaking commit, +but that is sadly not always the case. + [TOC] ## Is it the compiler? diff --git a/chromium/docs/clang_tidy.md b/chromium/docs/clang_tidy.md index 6b1ca7d0e27..112d7b02e1b 100644 --- a/chromium/docs/clang_tidy.md +++ b/chromium/docs/clang_tidy.md @@ -30,13 +30,70 @@ disabled. ### Adding a new check -If you'd like to propose the addition of a new check, please send an email to -cxx@chromium.org describing why you think the check is helpful. If the proposed -check is approved, you may turn it on, though please note that this is only +New checks require review from cxx@chromium.org. If you propose a check and it +gets approved, you may turn it on, though please note that this is only provisional approval: we get signal from users clicking "Not Useful" on comments. If feedback is overwhelmingly "users don't find this useful," the check may be removed. +Traditionally, petitions to add checks include [an +evaluation](https://docs.google.com/document/d/1i1KmXtDD4j_qjhmAdGlJ6UkYXByVX1Kp952Zusdcl5k/edit?usp=sharing) +of the check under review. Crucially, this includes two things: + +- a count of how many times this check fires across Chromium +- a random sample (>30) of places where the check fires across Chromium + +It's expected that the person proposing the check has manually surveyed every +clang-tidy diagnostic in the sample, noting any bugs, odd behaviors, or +interesting patterns they've noticed. If clang-tidy emits FixIts, these are +expected to be considered by the evaluation, too. + +An example of a previous proposal email thread is +[here](https://groups.google.com/a/chromium.org/g/cxx/c/iZ6-Y9ZhC3Q/m/g-8HzqmbAAAJ). + +#### Evaluating: running clang-tidy across Chromium + +Running clang-tidy requires some setup. First, you'll need to sync clang-tidy, +which requires adding `checkout_clang_tidy` to your `.gclient` file: + +``` +solutions = [ + { + 'custom_vars': { + 'checkout_clang_tidy': True, + }, + } +] +``` + +Your next run of `gclient runhooks` should cause clang-tidy to be synced. + +To run clang-tidy across all of Chromium, you'll need a checkout of Chromium's +[build/](https://chromium.googlesource.com/chromium/tools/build) repository. +Once you have that and a Chromium `out/` dir with an `args.gn`, running +clang-tidy across all of Chromium is a single command: + +``` +$ cd ${chromium}/src +$ ${chromium_build}/scripts/slave/recipes/tricium_clang_tidy_wrapper.resources/tricium_clang_tidy.py \ + --base_path $PWD \ + --out_dir out/Linux \ + --findings_file all_findings.json \ + --clang_tidy_binary $PWD/third_party/llvm-build/Release+Asserts/bin/clang-tidy \ + --all +``` + +All clang-tidy checks are run on Linux builds of Chromium, so please set up your +`args.gn` to build Linux. + +`all_findings.json` is where all of clang-tidy's findings will be dumped. The +format of this file is detailed in `tricium_clang_tidy.py`. + +**Note** that the above command will use Chromium's top-level `.clang-tidy` file +(or `.clang-tidy` files scattered throughout `third_party/`, depending on the +files we lint. In order to test a *new* check, you'll have to add it to +Chromium's top-level `.clang-tidy` file. + ### Ignoring a check If a check is invalid on a particular piece of code, clang-tidy supports `// diff --git a/chromium/docs/clangd.md b/chromium/docs/clangd.md index 99559663c4a..a289997a195 100644 --- a/chromium/docs/clangd.md +++ b/chromium/docs/clangd.md @@ -13,8 +13,14 @@ See [instructions](https://clang.llvm.org/extra/clangd/Installation.html#install **Googlers:** clangd has been installed on your glinux by default, just use `/usr/bin/clangd`. -Alternative: use the following command to build clangd from LLVM source, and you -will get the binary at +Alternative: download clangd from the official [Releases](https://github.com/clangd/clangd/releases) +page. + +Note: clangd 10.0.0 does not work with Chromium; use one of the pre-release +versions lower down on the Releases page until a newer version is released. + +If you prefer to build clangd locally, use the following command to build from +LLVM source, and you will get the binary at `out/Release/tools/clang/third_party/llvm/build/bin/clangd`. ``` @@ -36,8 +42,9 @@ source file. tools/clang/scripts/generate_compdb.py -p out/Release > compile_commands.json ``` -Note: the compilation database is not re-generated automatically, you'd need to -regenerate it manually when you have new files checked in. +Note: the compilation database is not regenerated automatically. You need to +regenerate it manually whenever build rules change, e.g., when you have new files +checked in or when you sync to head. If using Windows PowerShell, use the following command instead to set the output's encoding to UTF-8 (otherwise Clangd will hit "YAML:1:4: error: Got diff --git a/chromium/docs/code_reviews.md b/chromium/docs/code_reviews.md index 1fc688d17d4..0c6df1b3802 100644 --- a/chromium/docs/code_reviews.md +++ b/chromium/docs/code_reviews.md @@ -3,9 +3,8 @@ Code reviews are a central part of developing high-quality code for Chromium. All changes must be reviewed. -The bigger patch-upload-and-land process is covered in more detail the -[contributing code](https://www.chromium.org/developers/contributing-code) -page. +The general patch, upload, and land process is covered in more detail in the +[contributing code](contributing.md) page. # Code review policies @@ -186,8 +185,8 @@ Otherwise the reviewer won't know to review the patch. * Add the reviewer's email address in the code review tool's reviewer field like normal. - * Add a line "Tbr:" to the bottom of the change list - description. e.g. `Tbr:reviewer1@chromium.org,reviewer2@chromium.org` + * Add a line "Tbr: " to the bottom of the change list + description. e.g. `Tbr: reviewer1@chromium.org,reviewer2@chromium.org` * Type a message so that the owners in the TBR list can understand who is responsible for reviewing what, as part of their post-commit review diff --git a/chromium/docs/commit_checklist.md b/chromium/docs/commit_checklist.md index ffa6149fd65..7827b2bcb0d 100644 --- a/chromium/docs/commit_checklist.md +++ b/chromium/docs/commit_checklist.md @@ -1,16 +1,21 @@ # Commit Checklist for Chromium Workflow Here is a helpful checklist to go through before uploading change lists (CLs) on -Gerrit, which is the code review platform for the Chromium project. This -checklist is designed to be streamlined. See +Gerrit and during the code review process. Gerrit is the code review platform +for the Chromium project. This checklist is designed to be streamlined. See [contributing to Chromium][contributing] for a more thorough reference. The intended audience is software engineers who are unfamiliar with contributing to the Chromium project. Feel free to skip steps that are not applicable to the patch set you're currently uploading. +According to the Checklist Manifesto by Atul Gawande, checklists are a marvelous +tool for ensuring consistent quality in the work you produce. Checklists also +help you work more efficiently by ensuring you never skip a step or waste brain +power figuring out the next step to take. + [TOC] -## 1. Create a new branch +## 1. Create a new branch or switch to the correct branch You should create a new branch before starting any development work. It's helpful to branch early and to branch often in Git. Use the command @@ -18,16 +23,36 @@ helpful to branch early and to branch often in Git. Use the command `git checkout -b --track origin/master`. You may also want to set another local branch as the upstream branch. You can do -that with `git checkout -b --track `. +that with `git checkout -b --track `. Do this if +you want to split your work across multiple CLs, but some CLs have dependencies +on others. Mark the associated crbug as "started" so that other people know that you have -started work on the bug. Doing this can avoid duplicated work. +started working on the bug. Taking this step can avoid duplicated work. + +If you have already created a branch, don't forget to `git checkout +` to the correct branch before resuming development work. There's +few things more frustrating than to finish implementing your ideas or feedback, +and to spend hours debugging some mysterious bug, only to discover that the bug +was caused by working on the wrong branch this whole time. + +## 2. If there's a local upstream branch, rebase the upstream changes + +Suppose you have a downstream branch chained to an upstream branch. If you +commit changes to the upstream branch, and you want the changes to appear in +your downstream branch, you need to: + +* `git checkout ` to the downstream branch. +* Run `git rebase -i @{u}` to pull the upstream changes into the current + branch. +* Run `git rebase -i @{u}` again to rebase the downstream changes onto the + upstream branch. -## 2. Make your changes +## 3. Make your changes Do your thing. There's no further advice here about how to write or fix code. -## 3. Make sure the code builds correctly +## 4. Make sure the code builds correctly After making your changes, check that common targets build correctly: @@ -38,66 +63,74 @@ After making your changes, check that common targets build correctly: It's easy to inadvertently break one of the other builds you're not currently working on without realizing it. Even though the Commit Queue should catch any build errors, checking locally first can save you some time since the CQ Dry Run -can take a while. +can take a while to run, on the order of a few hours sometimes. -## 4. Test your changes +## 5. Test your changes -Make sure you hit every code path you changed. +Test your changes manually by running the X11 simulator or deploying your +changes to a test device. Follow the [Simple Chrome][simple-chrome] instructions +to deploy your changes to a test device. Make sure you hit every code path you +changed. -## 5. Write unit or browser tests for any new code +## 6. Write unit or browser tests for any new code Consider automating any manual testing you did in the previous step. -## 6. Ensure the code is formatted nicely +## 7. Ensure the code is formatted nicely Run `git cl format --js`. The `--js` option also formats JavaScript changes. -## 7. Review your changes +## 8. Review your changes Use `git diff` to review all of the changes you've made from the previous commit. Use `git upstream-diff` to review all of the changes you've made from the upstream branch. The output from `git upstream-diff` is what will be uploaded to Gerrit. -## 8. Stage relevant files for commit +## 9. Stage relevant files for commit Run `git add ` for all of the files you've modified that you want to include in the CL. Unlike other version-control systems such as svn, you have to specifically `git add` the files you want to commit before calling `git commit`. -## 9. Commit your changes +## 10. Commit your changes Run `git commit`. Be sure to write a useful commit message. Here are some [tips for writing good commit messages][uploading-a-change-for-review]. A -shortcut for combining steps 8 and 9 is `git commit -a -m `. +shortcut for combining steps the previous step and this one is `git commit -a -m +`. -## 10. Squash your commits +## 11. Squash your commits If you have many commits on your current branch, and you want to avoid some nasty commit-by-commit merge conflicts in the next step, consider collecting all your changes into one commit. Run `git rebase -i @{u}`. The `@{u}` is a -short-hand pointer for the upstream branch, which is usually origin/master. -After running the `git rebase` command, you should see a list of commits, with -each commit starting with the word "pick". Make sure the first commit says -"pick" and change the rest from "pick" to "squash". This will squash each commit -into the previous commit, which will continue until each commit is squashed into -the first commit. - -## 11. Rebase your local repository - -Rebasing is a neat way to resolve any merge conflict errors on your CL. Run -`git rebase-update`. This command updates all of your local branches with -remote changes that have landed since you started development work, which -could've been a while ago. It also deletes any branches that match the remote -repository, such as after the CL associated with that branch has been merged. -In summary, `git rebse-update` cleans up your local branches. +short-hand pointer for the upstream branch, which is usually origin/master, but +can also be one of your local branches. After running the `git rebase` command, +you should see a list of commits, with each commit starting with the word +"pick". Make sure the first commit says "pick" and change the rest from "pick" +to "squash". This will squash each commit into the previous commit, which will +continue until each commit is squashed into the first commit. + +An alternative way to squash your commits into a single commit is to do `git +commit --amend` in the previous step. + +## 12. Rebase your local repository + +Rebasing is a neat way to sync changes from the remote repository and resolve +any merge conflict errors on your CL. Run `git rebase-update`. This command +updates all of your local branches with remote changes that have landed since +you started development work, which could've been a while ago. It also deletes +any branches that match the remote repository, such as after the CL associated +with that branch has been merged. In summary, `git rebase-update` cleans up your +local branches. You may run into rebase conflicts. Fix them manually before proceeding with `git rebase --continue`. Note that rebasing has the potential to break your build, so you might want to try re-building afterwards. -## 12. Upload the CL to Gerrit +## 13. Upload the CL to Gerrit Run `git cl upload`. Some useful options include: @@ -105,21 +138,22 @@ Run `git cl upload`. Some useful options include: * `-r ` will add reviewers. * `-b ` automatically populates the bug reference line of the commit message. +* `--edit-description` will let you update the commit message. -## 13. Check the CL again in Gerrit +## 14. Check the CL again in Gerrit Run `git cl web` to go to the Gerrit URL associated with the current branch. Open the latest patch set and verify that all of the uploaded files are correct. Click `Expand All` to check over all of the individual line-by-line changes -again. +again. Basically do a self-review before asking your reviewers for a review. -## 14. Make sure all auto-regression tests pass +## 15. Make sure all auto-regression tests pass Click `CQ Dry Run`. Fix any errors because otherwise the CL won't pass the commit queue (CQ) checks. Consider waiting for the CQ Dry Run to pass before notifying your reviewers, in case the results require major changes in your CL. -## 15. Add reviewers to review your code +## 16. Add reviewers to review your code Click `Find Owners` or run `git cl owners` to find file owners to review your code and instruct them about which parts you want them to focus on. Add anyone @@ -129,7 +163,7 @@ your CL touches. For your CL to land, you need an approval from an owner for each file you've changed, unless you are an owner of some files, in which case you don't need separate owner approval for those files. -## 16. Implement feedback from your reviewers +## 17. Implement feedback from your reviewers Then go through this commit checklist again. Reply to all comments from the reviewers on Gerrit and mark all resolved issues as resolved (clicking `Done` or @@ -138,7 +172,7 @@ receive a notification. Doing this signals that your CL is ready for review again, since the assumption is that your CL is not ready for review until you hit reply. -## 17. Land your CL +## 18. Land your CL Once you have obtained a Looks Good To Me (LGTM), which is reflected by a Code-Review+1 in Gerrit, from at least one owner for each file, then you have @@ -147,7 +181,7 @@ of your reviewers to approve your changes as well, even if they're not owners. Click `Submit to CQ` to try your change in the commit queue (CQ), which will land it if successful. -## 18. Cleanup +## 19. Cleanup After your CL is landed, you can use `git rebase-update` or `git cl archive` to clean up your local branches. These commands will automatically delete merged @@ -155,4 +189,5 @@ branches. Mark the associated crbug as "fixed". [//]: # (the reference link section should be alphabetically sorted) [contributing]: contributing.md +[simple-chrome]: https://chromium.googlesource.com/chromiumos/docs/+/master/simple_chrome_workflow.md [uploading-a-change-for-review]: contributing.md#Uploading-a-change-for-review diff --git a/chromium/docs/contributing.md b/chromium/docs/contributing.md index bbaaacd315d..753586fcc57 100644 --- a/chromium/docs/contributing.md +++ b/chromium/docs/contributing.md @@ -327,6 +327,10 @@ general rules of thumb can be helpful in navigating how to structure changes: find a product in the Chromium repositories that depends on that line of code or else the line of code should be removed. + Completely new additions to the project (for example, support for a new OS + or architecture, or a new top-level directory for a new sub-project) must + be approved by [//ENG_REVIEW_OWNERS](../ENG_REVIEW_OWNERS). + - **Code should only be moved to a central location (e.g., //base) when multiple consumers would benefit.** We should resist the temptation to build overly generic common libraries as that can lead to code bloat and diff --git a/chromium/docs/design/sandbox.md b/chromium/docs/design/sandbox.md index 47bf871bf41..a73501f8c00 100644 --- a/chromium/docs/design/sandbox.md +++ b/chromium/docs/design/sandbox.md @@ -463,6 +463,14 @@ Rules can only be added before each target process is spawned, and cannot be modified while a target is running, but different targets can have different rules. +### Diagnostics + +In Chromium, the policies associated with active processes can be viewed at +chrome://sandbox. Tracing of the `sandbox` category will output the policy used +when a process is launched. Tracing can be enabled using chrome://tracing or by +using the `--trace-startup=-*,disabled-by-default-sandbox` command line flag. +Trace output can be investigated with `//tools/win/trace-sandbox-viewer.py`. + ## Target bootstrapping Targets do not start executing with the restrictions specified by policy. They diff --git a/chromium/docs/enterprise/add_new_policy.md b/chromium/docs/enterprise/add_new_policy.md index d90cd69ff71..9c5f400f583 100644 --- a/chromium/docs/enterprise/add_new_policy.md +++ b/chromium/docs/enterprise/add_new_policy.md @@ -37,10 +37,12 @@ Usually you need a policy when sure you get the version and feature flags (such as dynamic_refresh and supported_on) right. - Here are the most used attributes. Please note that, all attributes - below other than `supported_on` and `default_for_enterprise_users` do - not change the code behavior. - - `supported_on`: It controls the platform and Chrome milestone the - policy supports. + below other than `supported_on`, `future_on' and + `default_for_enterprise_users` do not change the code behavior. + - `supported_on` and `future_on`: They control the platforms that the + policy supports. `supported_on` is used for released platforms with + milestone range while `future_on` is used for unreleased platforms. + See **Launch a policy** below for more information. - `default_for_enterprise_users`: Its value is applied as a mandatory policy for managed users on Chrome OS unless a different setting is explicitly set. @@ -51,9 +53,6 @@ Usually you need a policy when - `can_be_recommended`: It tells the admin whether they can mark the policy as recommended and allow the user to override it in the UI, using a command line switch or an extension. - - `future`: It hides the policy from auto-generated templates and - documentation. It's used when your policy needs multiple milestone - development. - The complete list of attributes and their expected values can be found in the [policy_templates.json](https://cs.chromium.org/chromium/src/components/policy/resources/policy_templates.json). @@ -152,6 +151,33 @@ Usually you need a policy when 10. If your policy has interactions with other policies, make sure to document, test and cover these by automated tests. +## Launch a policy +1. When adding a new policy, put the platforms it will be supported in the + `future_on` list. + - The policy is hidden from any auto-generated template or documentation on + those platforms. + - The policy will also be unavailable on Beta and Stable channel unless it's + enabled specifically by + [EnableExperimentalPolicies](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=EnableExperimentalPolicies) + policy. +2. Implement the policy, get launch approval if necessary. +3. If the policy needs to be tested with small set of users first, keep the + platforms in the `future_on` list and running the tester program with the + [EnableExperimentalPolicies](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=EnableExperimentalPolicies) + policy. +4. Move the launched platforms from `future_on` to `supported_on` and set the + 'since_version' of those platforms to the milestone for which the launch + approval was granted. +5. If the 'since_version' is set to a earlier milestone, you need to merge + back all necessary commits. + +**Do not use finch to control policy launch process.** + +Policies are inherently switches that admins will turn on if they need. Getting +inconsistent behavior based on factors outside of their control only causes +confusion and is source for support requests. Use the step 3 above if the policy +needs external testers before being officially announced. + ## Examples Here is an example based on the instructions above. It's a good, simple place to @@ -221,6 +247,7 @@ The presubmit checks perform the following verifications: before a new stable release has rolled out. Normally such a change should eventually be merged into the stable branch before the release. + 3. `supported_on` list is empty. 2. If the policy is considered **unreleased**, all changes to it are allowed. @@ -261,6 +288,15 @@ The presubmit checks perform the following verifications: 1. Dictionary policies can have some of their "required" fields removed in order to be less restrictive. +4. A policy is **partially released** if both `supported_on` and + `future_on` list are not empty. + +5. The **partially released** policy is considered as a **released** policy + and only the `future_on` list can be modified freely. However, any + platform in the `supported_on` list cannot be moved back to the `future_on` + list. + + ## Cloud Policy **For Googlers only**: The Cloud Policy will be maintained by the Admin console @@ -292,4 +328,7 @@ than regular consumer behavior. ### Additional Notes -1. policy_templates.json is actually a Python dictionary even though the file name contains *json*. +1. policy_templates.json is actually a Python dictionary even though the file + name contains *json*. +2. The `future_on` flag can disable policy on Beta of Stable channel only if the + policy value is copied to `PrefService` in Step 3 of **Adding a new policy**. diff --git a/chromium/docs/enterprise/extension_query.py b/chromium/docs/enterprise/extension_query.py index c1a23974efc..f1e6dd1c758 100755 --- a/chromium/docs/enterprise/extension_query.py +++ b/chromium/docs/enterprise/extension_query.py @@ -1,5 +1,5 @@ #!/usr/bin/env python -# Copyright (c) 2020 The Chromium Authors. All rights reserved. +# Copyright 2020 The Chromium Authors. All rights reserved. # Use of this source code is governed by a BSD-style license that can be # found in the LICENSE file. """Transform CBCM Takeout API Data (Python3).""" @@ -8,6 +8,7 @@ import argparse import csv import json import sys +import time import google_auth_httplib2 @@ -41,26 +42,20 @@ def ComputeExtensionsList(extensions_list, data): key = key + ' @ ' + extension['version'] if key not in extensions_list: current_extension = { - 'name': - extension['name'], - 'permissions': - extension['permissions'] - if 'permissions' in extension else '', - 'installed': - set(), - 'disabled': - set(), - 'forced': - set() + 'name': extension.get('name', ''), + 'permissions': extension.get('permissions', ''), + 'installed': set(), + 'disabled': set(), + 'forced': set() } else: current_extension = extensions_list[key] machine_name = device['machineName'] current_extension['installed'].add(machine_name) - if 'installType' in extension and extension['installType'] == 3: + if extension.get('installType', '') == 'ADMIN': current_extension['forced'].add(machine_name) - if 'disabled' in extension and extension['disabled']: + if extension.get('disabled', False): current_extension['disabled'].add(machine_name) extensions_list[key] = current_extension @@ -170,11 +165,21 @@ def main(args): browsers_processed = 0 while True: print('Making request to server ...') - response = http.request(base_request_url + '?' + request_parameters, - 'GET')[1] - if isinstance(response, bytes): - response = response.decode('utf-8') - data = json.loads(response) + + retrycount = 0 + while retrycount < 5: + response = http.request(base_request_url + '?' + request_parameters, + 'GET')[1] + + if isinstance(response, bytes): + response = response.decode('utf-8') + data = json.loads(response) + if 'browsers' not in data: + print('Response error, retrying...') + time.sleep(3) + retrycount += 1 + else: + break browsers_in_data = len(data['browsers']) print('Request returned %s results, analyzing ...' % (browsers_in_data)) diff --git a/chromium/docs/enterprise/extension_query_py2.py b/chromium/docs/enterprise/extension_query_py2.py index 73856278e65..2bf496b85e9 100755 --- a/chromium/docs/enterprise/extension_query_py2.py +++ b/chromium/docs/enterprise/extension_query_py2.py @@ -1,8 +1,7 @@ #!/usr/bin/env python -# Copyright (c) 2020 The Chromium Authors. All rights reserved. +# Copyright 2020 The Chromium Authors. All rights reserved. # Use of this source code is governed by a BSD-style license that can be # found in the LICENSE file. - """Transform CBCM Takeout API Data (Python2).""" from __future__ import print_function @@ -44,30 +43,25 @@ def ComputeExtensionsList(extensions_list, data): key = key + ' @ ' + extension['version'] if key not in extensions_list: current_extension = { - 'name': - extension['name'], - 'permissions': - extension['permissions'] - if 'permissions' in extension else '', - 'installed': - set(), - 'disabled': - set(), - 'forced': - set() + 'name': extension.get('name', ''), + 'permissions': extension.get('permissions', ''), + 'installed': set(), + 'disabled': set(), + 'forced': set() } else: current_extension = extensions_list[key] machine_name = device['machineName'] current_extension['installed'].add(machine_name) - if 'installType' in extension and extension['installType'] == 3: + if extension.get('installType', '') == 'ADMIN': current_extension['forced'].add(machine_name) - if 'disabled' in extension and extension['disabled']: + if extension.get('disabled', False): current_extension['disabled'].add(machine_name) extensions_list[key] = current_extension + def ToUtf8(data): """Ensures all the values in |data| are encoded as UTF-8. @@ -84,6 +78,7 @@ def ToUtf8(data): entry[prop] = unicode(value).encode('utf-8') yield entry + def DictToList(data, key_name='id'): """Converts a dict into a list. @@ -181,8 +176,17 @@ def main(args): browsers_processed = 0 while True: print('Making request to server ...') - data = json.loads( - http.request(base_request_url + '?' + request_parameters, 'GET')[1]) + retrycount = 0 + while retrycount < 5: + data = json.loads( + http.request(base_request_url + '?' + request_parameters, 'GET')[1]) + + if 'browsers' not in data: + print('Response error, retrying...') + time.sleep(3) + retrycount += 1 + else: + break browsers_in_data = len(data['browsers']) print('Request returned %s results, analyzing ...' % (browsers_in_data)) diff --git a/chromium/docs/fuchsia_build_instructions.md b/chromium/docs/fuchsia_build_instructions.md index 5c5d2ac39d4..4dee4bf448b 100644 --- a/chromium/docs/fuchsia_build_instructions.md +++ b/chromium/docs/fuchsia_build_instructions.md @@ -91,7 +91,7 @@ target_os = ['fuchsia'] You will then need to run: ```shell -$ gclient runhooks +$ gclient sync ``` This makes sure the Fuchsia SDK is available in third\_party and keeps it up to diff --git a/chromium/docs/fuchsia_gardening.md b/chromium/docs/fuchsia_gardening.md index d248c9f0da8..63c11245f04 100644 --- a/chromium/docs/fuchsia_gardening.md +++ b/chromium/docs/fuchsia_gardening.md @@ -34,5 +34,7 @@ While the Gardener takes primary responsibility for each of these areas during t The waterfall is green, the try-bots reliable, SDK is rolling and pigs soar majestically in the sky. Fear not, gentle Gardener, you still have a valuable role to play! +Googlers: The current gardener can be found at [go/cr-fuchsia-cop](http://go/cr-fuchsia-cop). + * Look for tests that have been filtered under Fuchsia, and diagnose them. * File a new bug, or upate the filter to refer to existing bugs, as appropriate. diff --git a/chromium/docs/gpu/gpu_testing.md b/chromium/docs/gpu/gpu_testing.md index a2d9b20470d..958801a0f14 100644 --- a/chromium/docs/gpu/gpu_testing.md +++ b/chromium/docs/gpu/gpu_testing.md @@ -278,11 +278,11 @@ being tested. This *should* mean that the pixel tests will automatically work when run locally. However, if the local run detection code fails for some reason, you can manually pass some flags to force the same behavior: -In order to get around the local run issues, simply pass the `--local-run=1` -flag to the tests. This will disable uploading, but otherwise go through the -same steps as a test normally would. Each test will also print out `file://` -URLs to the produced image, the closest image for the test known to Gold, and -the diff between the two. +In order to get around the local run issues, simply pass the +`--local-pixel-tests` flag to the tests. This will disable uploading, but +otherwise go through the same steps as a test normally would. Each test will +also print out `file://` URLs to the produced image, the closest image for the +test known to Gold, and the diff between the two. Because the image produced by the test locally is likely slightly different from any of the approved images in Gold, local test runs are likely to fail during @@ -292,7 +292,7 @@ comparison. When using `--no-skia-gold-failure`, you'll also need to pass the `--passthrough` flag in order to actually see the link output. Example usage: -`run_gpu_integration_test.py pixel --no-skia-gold-failure --local-run=1 +`run_gpu_integration_test.py pixel --no-skia-gold-failure --local-pixel-tests --passthrough` If, for some reason, the local run code is unable to determine what the git @@ -300,7 +300,7 @@ revision is, simply pass `--git-revision aabbccdd`. Note that `aabbccdd` must be replaced with an actual Chromium src revision (typically whatever revision origin/master is currently synced to) in order for the tests to work. This can be done automatically using: -``run_gpu_integration_test.py pixel --no-skia-gold-failure --local-run +``run_gpu_integration_test.py pixel --no-skia-gold-failure --local-pixel-tests --passthrough --git-revision `git rev-parse origin/master` `` ## Running Binaries from the Bots Locally @@ -628,6 +628,9 @@ Here are some examples: * A change to Blink's memory purging primitive which caused intermittent timeouts of WebGL conformance tests on all platforms ([Issue 840988](http://crbug.com/840988)). +* Screen DPI being inconsistent across seemingly identical Linux machines, + causing the Maps pixel test to flakily produce incorrectly sized images + ([Issue 1091410](https://crbug.com/1091410)). If you notice flaky test failures either on the GPU waterfalls or try servers, please file bugs right away with the component Internals>GPU>Testing and diff --git a/chromium/docs/gpu/gpu_testing_bot_details.md b/chromium/docs/gpu/gpu_testing_bot_details.md index 7255a9ea027..84f40dc0311 100644 --- a/chromium/docs/gpu/gpu_testing_bot_details.md +++ b/chromium/docs/gpu/gpu_testing_bot_details.md @@ -251,14 +251,11 @@ sorry): * [`pools.cfg`][pools.cfg] * Defines the Swarming pools for GCEs and Mac VMs used for manually triggered trybots. -* [`bot_config.py`][bot_config.py] - * Defines the stable GPU driver and OS versions in GPU Swarming pools. [infradata/config]: https://chrome-internal.googlesource.com/infradata/config [gpu.star]: https://chrome-internal.googlesource.com/infradata/config/+/master/configs/chromium-swarm/starlark/bots/chromium/gpu.star [chromium.star]: https://chrome-internal.googlesource.com/infradata/config/+/master/configs/chromium-swarm/starlark/bots/chromium/chromium.star [pools.cfg]: https://chrome-internal.googlesource.com/infradata/config/+/master/configs/chromium-swarm/pools.cfg -[bot_config.py]: https://chrome-internal.googlesource.com/infradata/config/+/master/configs/chromium-swarm/scripts/bot_config.py [main.star]: https://chrome-internal.googlesource.com/infradata/config/+/master/main.star [vms.cfg]: https://chrome-internal.googlesource.com/infradata/config/+/master/configs/gce-provider/vms.cfg @@ -666,10 +663,6 @@ or OS update. To do this: 1. Make sure that all of the current Swarming jobs for this OS and GPU configuration are targeted at the "stable" version of the driver and the OS in [`waterfalls.pyl`][waterfalls.pyl] and [`mixins.pyl`][mixins.pyl]. - Make sure that there are "named" stable versions of the driver and the OS - there, which target the `_TARGETED_DRIVER_VERSIONS` and - `_TARGETED_OS_VERSIONS` dictionaries in [`bot_config.py`][bot_config.py] - (Google internal). 1. File a `Build Infrastructure` bug, component `Infra>Labs`, to have ~4 of the physical machines already in the Swarming pool upgraded to the new version of the driver or the OS. @@ -684,51 +677,41 @@ or OS update. To do this: it'll be necessary to follow the instructions on [updating Gold baselines (step #4)][updating gold baselines]. 1. Watch the new machine for a day or two to make sure it's stable. -1. When it is, update [`bot_config.py`][bot_config.py] (Google internal) - to *add* a mapping between the new driver version and the "stable" version. - For example: +1. When it is, add the experimental driver/OS to the `_stable` mixin using the + swarming OR operator `|`. For example: ``` - _TARGETED_DRIVER_VERSIONS = { - # NVIDIA Quadro P400, Ubuntu Stable version - '10de:1cb3-384.90': 'nvidia-quadro-p400-ubuntu-stable', - # NVIDIA Quadro P400, new Ubuntu Stable version - '10de:1cb3-410.78': 'nvidia-quadro-p400-ubuntu-stable', - # ... - } - ``` - - And/or a mapping between the new OS version and the "stable" version. - For example: - - ``` - _TARGETED_OS_VERSIONS = { - # Linux NVIDIA Quadro P400 - '10de:1cb3': { - 'Ubuntu-14.04': 'linux-nvidia-stable', - 'Ubuntu-19.04': 'linux-nvidia-stable', + 'win10_intel_hd_630_stable': { + 'swarming': { + 'dimensions': { + 'gpu': '8086:5912-26.20.100.7870|8086:5912-26.20.100.8141', + 'os': 'Windows-10', + 'pool': 'chromium.tests.gpu', + }, }, - # ... } ``` - The new driver or OS version should match the one just added for the - experimental bot. Get this CL reviewed and landed. - [Sample CL (Google internal)][sample targeted version cl]. + This will cause tests triggered using the `_stable` mixin to run on either + the old stable dimension or the experimental/new stable dimension. + + **NOTE** There is a hard cap of 8 combinations in swarming, so you can only + use the OR operator in up to 3 dimensions if each dimension only has two + options. More than two options per dimension is allowed as long as the total + number of combinations is 8 or less. 1. After it lands, ask the Chrome Infrastructure Labs team to roll out the driver update across all of the similarly configured bots in the swarming pool. 1. If necessary, update pixel test expectations and remove the suppressions added above. -1. Remove the old driver or OS version from [`bot_config.py`][bot_config.py], - leaving the "stable" driver version pointing at the newly upgraded version. +1. Remove the old driver or OS version from the `_stable` mixin, leaving just + the new stable version. Note that we leave the experimental bot in place. We could reclaim it, but it seems worthwhile to continuously test the "next" version of graphics drivers as well as the current stable ones. [sample driver cl]: https://chromium-review.googlesource.com/c/chromium/src/+/1726875 -[sample targeted version cl]: https://chrome-internal-review.googlesource.com/c/infradata/config/+/1602377 [updating gold baselines]: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/gpu/pixel_wrangling.md#how-to-keep-the-bots-green ## Credentials for various servers diff --git a/chromium/docs/how_cc_works.md b/chromium/docs/how_cc_works.md index 2b1f897ce58..fa3b84eb1cf 100644 --- a/chromium/docs/how_cc_works.md +++ b/chromium/docs/how_cc_works.md @@ -131,13 +131,13 @@ There are a number of heuristics to determine when and how to change rasterizati These aren’t perfect, but change them at your own peril. 🐉🐉🐉 -### PictureImageLayer +#### Directly composited images -A subclass of PictureLayer. -This is a special case for composited images in Blink. -If an image gets a composited layer but has no borders or padding (i.e. the painted content is exactly equal to the image) then some work can be saved here. -It "rasters" the image at fixed scales such that scaling this image is performant. -This is really a savings for software raster and in a gpu raster world such layers should never be created. +A specialized raster mode of PictureLayerImpl. +If a PictureLayer's DisplayItemList consists of a single drawImageRect DrawOp, we use different logic to determine what the raster scale of the image should end up being. +The layer is rastered at fixed scales such that scaling this image is performant. +The default raster scale is chosen such that the image will raster at its intrinsic side, then that scale is adjusted, based on how close it is to the ideal scale. +See PictureLayerImpl::ShouldAdjustRasterScale and RecalculateRasterScales for more details. ### TextureLayer diff --git a/chromium/docs/ios/build_instructions.md b/chromium/docs/ios/build_instructions.md index 5695097a072..2a42d01be38 100644 --- a/chromium/docs/ios/build_instructions.md +++ b/chromium/docs/ios/build_instructions.md @@ -76,6 +76,11 @@ build directories under `out` for Release and Debug device and simulator builds, and generates an appropriate Xcode workspace (`out/build/all.xcworkspace`) as well. +Warning: *do not open `out/build/products.xcodeproj` as this file does not +configure the "Legacy Build System". If you do open this file, many things +won't work properly (clicking on an error won't open the corresponding file, +...).* + More information about [developing with Xcode](xcode_tips.md). You can customize the build by editing the file `$HOME/.setup-gn` (create it if diff --git a/chromium/docs/ios/xcode_tips.md b/chromium/docs/ios/xcode_tips.md index 0e643693dce..63b11367899 100644 --- a/chromium/docs/ios/xcode_tips.md +++ b/chromium/docs/ios/xcode_tips.md @@ -5,8 +5,9 @@ to develop Chrome for iOS. ## Background -### .xcworkspace and .xcproject +### .xcworkspace and .xcodeproj +* Open all.xcworkspace only. * Generated from BUILD.gn files. * Don't make changes to it as it is a "fake" representation of the project - changes will not be committed @@ -15,6 +16,10 @@ to develop Chrome for iOS. * Added BUILD.gn files/`source_sets` need to be referenced from other ones as a `dep` in order for it to be shown in xcode. +Warning: *do not open the `.xcodeproj` as this file does not configure the +"Legacy Build System". If you do open this file, many things won't work +properly (clicking on an error won't open the corresponding file, ...).* + ### Adding new files * Create new files with `tools/boilerplate.py` diff --git a/chromium/docs/linux/debugging.md b/chromium/docs/linux/debugging.md index fd96694d8ca..03b29e3dcb8 100644 --- a/chromium/docs/linux/debugging.md +++ b/chromium/docs/linux/debugging.md @@ -258,9 +258,12 @@ can also step or execute backwards. This works by first recording a trace and then debugging based on that. I recommend installing it by compiling [from source](https://github.com/mozilla/rr/wiki/Building-And-Installing). -Currently you must apply a patch adding -[support for recording the MADV_WIPEONFORK](https://bugs.chromium.org/p/chromium/issues/detail?id=1082304#c6) -syscall as upstream rr triggers an internal assert on this call. +As of May 2020, you must build from source for [`MADV_WIPEONFORK` +support](https://bugs.chromium.org/p/chromium/issues/detail?id=1082304). If you +get the following error, rr is too old: +``` +Expected EINVAL for 'madvise' but got result 0 (errno SUCCESS); unknown madvise(18) +``` Once installed, you can use it like this: ``` diff --git a/chromium/docs/mac/triage.md b/chromium/docs/mac/triage.md index 2ece59d32c1..7fc93c93eef 100644 --- a/chromium/docs/mac/triage.md +++ b/chromium/docs/mac/triage.md @@ -155,6 +155,6 @@ triage processes: [unconfirmed]: https://bugs.chromium.org/p/chromium/issues/list?q=OS%3DMac%20status%3AUnconfirmed%20-component%3ABlink%2CEnterprise%2CInternals%3ENetwork%2CPlatform%3EDevtools%2CServices%3ESyncs%2CUI%3EBrowser%3EPasswords&can=2 [untriaged-m]: https://bugs.chromium.org/p/chromium/issues/list?q=has%3AMac%20status%3AUntriaged&can=2 -[untriaged-c]: https://bugs.chromium.org/p/chromium/issues/list?q=OS%3DMac%20-OS%3DWindows%2CLinux%2CChrome%2CAndroid%2CiOS%20status%3AUntriaged%20-component%3AAdmin%2CBlink%2CInfra%2CInternals%3EHeadless%2CInternals%3ENetwork%2CInternals%3EPlugins%3EPDF%2CInternals%3EPrinting%2CInternals%3ESkia%2CInternals%3EUpdater%2CInternals%3EViews%2CIO%3EBluetooth%2CIO%3EUSB%2CPlatform%2CServices%3EChromoting%2CTest%3ETelemetry%2CUI%3EBrowser%3EWebUI&can=2 +[untriaged-c]: https://bugs.chromium.org/p/chromium/issues/list?q=OS%3DMac%20-OS%3DWindows%2CLinux%2CChrome%2CAndroid%2CiOS%20status%3AUntriaged%20-component%3AAdmin%2CBlink%2CInfra%2CInternals%3EHeadless%2CInternals%3ENetwork%2CInternals%3EPlugins%3EPDF%2CInternals%3EPrinting%2CInternals%3ESkia%2CInternals%3EUpdater%2CInternals%3EViews%2CIO%3EBluetooth%2CIO%3EUSB%2CPlatform%2CServices%3EChromoting%2CTest%3ETelemetry%2CUI%3EBrowser%3EWebAppInstalls%2CUI%3EBrowser%3EWebUI&can=2 [available]: https://bugs.chromium.org/p/chromium/issues/list?q=has%3AMac%20status%3AAvailable&can=2 [assigned]: https://bugs.chromium.org/p/chromium/issues/list?q=has%3AMac%20status%3AAssigned&can=2 diff --git a/chromium/docs/media/gpu/video_decoder_perf_test_usage.md b/chromium/docs/media/gpu/video_decoder_perf_test_usage.md index 26bf41c8537..f5d4c6690dd 100644 --- a/chromium/docs/media/gpu/video_decoder_perf_test_usage.md +++ b/chromium/docs/media/gpu/video_decoder_perf_test_usage.md @@ -92,6 +92,10 @@ Multiple command line arguments can be given to the command: will be stored in the current working directory. --use_vd use the new VD-based video decoders, instead of the default VDA-based video decoders. + --use_vd_vda use the new VD-based video decoders with a wrapper + that translates to the VDA interface, used to test + interaction with older components expecting the VDA + interface. --gtest_help display the gtest help and exit. --help display this help and exit. diff --git a/chromium/docs/media/gpu/video_decoder_test_usage.md b/chromium/docs/media/gpu/video_decoder_test_usage.md index 321e48f236e..9d4e1bd9512 100644 --- a/chromium/docs/media/gpu/video_decoder_test_usage.md +++ b/chromium/docs/media/gpu/video_decoder_test_usage.md @@ -65,6 +65,10 @@ Multiple command line arguments can be given to the command: --disable_validator disable frame validation. --use_vd use the new VD-based video decoders, instead of the default VDA-based video decoders. + --use_vd_vda use the new VD-based video decoders with a wrapper + that translates to the VDA interface, used to test + interaction with older components expecting the VDA + interface. --output_frames write the selected video frames to disk, possible values are "all|corrupt". diff --git a/chromium/docs/media/gpu/video_encoder_test_usage.md b/chromium/docs/media/gpu/video_encoder_test_usage.md new file mode 100644 index 00000000000..688d497cb5c --- /dev/null +++ b/chromium/docs/media/gpu/video_encoder_test_usage.md @@ -0,0 +1,73 @@ +# Video Encoder tests +The video encoder tests are a set of tests that validate various video encoding +scenarios. They are accompanied by the video encoder performance tests that can +be used to measure a video encoder's performance. + +These tests run directly on top of the video encoder implementation, and +don't require the full Chrome browser stack. They are built on top of the +[GoogleTest](https://github.com/google/googletest/blob/master/README.md) +framework. + +__Note:__ Currently these tests are under development and functionality is still +limited. + +[TOC] + +## Running from Tast +Running these tests from Tast is not supported yet. + +## Running manually +To run the video encoder tests manually the _video_encode_accelerator_tests_ +target needs to be built and deployed to the device being tested. Running +the video encoder tests can be done by executing: + + ./video_encode_accelerator_tests [