BASELINE: Update Chromium to 85.0.4183.14085-based

Change-Id: Iaa42f4680837c57725b1344f108c0196741f6057
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>

4 files changed, 49 insertions, 22 deletions

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 <branch_name> .
 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 <chromeos root>/build/$BOARD/usr/include/brlapi.h <chrome_root>/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).