BASELINE: Update Chromium to 73.0.3683.37

Change-Id: I08c9af2948b645f671e5d933aca1f7a90ea372f2
Reviewed-by: Michael Brüning <michael.bruning@qt.io>

9 files changed, 98 insertions, 89 deletions

diff --git a/chromium/ipc/BUILD.gn b/chromium/ipc/BUILD.gn
index b5682e3eef5..cb7e4a21840 100644
--- a/chromium/ipc/BUILD.gn
+++ b/chromium/ipc/BUILD.gn
@@ -103,6 +103,16 @@ component("ipc") {
     "//base",
   ]
 
+  # TODO(https://crbug.com/916130): AFDO causes a substantial size increase in
+  # nacl_helper that originates from here. This is apparently due to some
+  # mixture of inlining, CFI, and (potentially) speculative devirtualization.
+  # Work around that by locally disabling AFDO.
+  #
+  # nacl_helper is only available on Linux.
+  if (is_linux) {
+    configs -= [ "//build/config/compiler:afdo" ]
+  }
+
   if (enable_ipc_fuzzer) {
     public_configs = [ "//tools/ipc_fuzzer:ipc_fuzzer_config" ]
   }
diff --git a/chromium/ipc/README.md b/chromium/ipc/README.md
index 5187f2573bc..ad1882a4b4e 100644
--- a/chromium/ipc/README.md
+++ b/chromium/ipc/README.md
@@ -19,6 +19,21 @@ various tools available to help with conversion of legacy IPC messages to Mojo.
 It assumes familiarity with [Mojom](/mojo/public/tools/bindings) syntax and
 general use of Mojo [C++ bindings](/mojo/public/cpp/bindings).
 
+The existing messages that still need to be converted are tracked in two
+spreadsheets:
+
+[Chrome IPC to Mojo migration](
+https://docs.google.com/spreadsheets/d/1pGWX_wxGdjAVtQOmlDDfhuIc3Pbwg9FtvFXAXYu7b7c/edit#gid=0) -
+for non-web platform messages
+
+[Mojoifying Platform Features](
+https://docs.google.com/spreadsheets/d/1VIINt17Dg2cJjPpoJ_HY3HI0uLpidql-1u8pBJtpbGk/edit#gid=1603373208) -
+for web platform messages
+
+Ownership of items is claimed by specifying a username in the 'Owner' field to
+prevent duplication of effort. If you are not very familiar with the messages
+you plan to convert, it might be worth asking the owner first.
+
 In traditional Chrome IPC, we have One Big Pipe (the `IPC::Channel`) between
 each connected process. Sending an IPC from one process to another means knowing
 how to get a handle to the Channel interface (*e.g.,*
@@ -48,7 +63,7 @@ of life?
 ### Moving Messages to Services
 
 We have a small but growing number of services defined in
-[`//services`](https://cs.chromium.org/chromium/src/services), each of which has
+[`//services`](https://cs.chromium.org/chromium/src/services/), each of which has
 some set of public interfaces defined in their `public/interfaces` subdirectory.
 In the limit, this is the preferred destination for any message conversions
 pertaining to foundational system services (more info at
@@ -128,7 +143,7 @@ others still on the Channel.
 If ordering really matters with respect to other legacy messages in the system,
 as is often the case for *e.g.* frame and navigation-related messages, you
 almost certainly want to take advantage of
-[Channel-associated interfaces](#Using-Channel-associated-Interfaces) to
+[Channel-associated interfaces](#Using-Channel_associated-Interfaces) to
 eliminate any risk of introducing subtle behavioral changes.
 
 Even if ordering only matters among a small set of messages which you intend to
@@ -166,7 +181,12 @@ interface PngDecoder {
 };
 ```
 
-and you'll also want to define the implementation within
+You will need to update the relevant BUILD.gn target with the newly added mojom
+file. See [this section](
+https://chromium.googlesource.com/chromium/src/+/master/mojo/public/cpp/bindings/README.md#getting-started)
+for details.
+
+You'll also want to define the implementation within
 `//services/data_decoder`, plugging in some appropriate binder so the service
 knows how to bind incoming interface requests to your implementation:
 
@@ -195,6 +215,8 @@ lots of ugly code which sets up a `UtilityProcessHost` and replacing it with
 something like:
 
 ``` cpp
+#include "services/data_decoder/public/mojom/png_decoder.mojom.h"
+...
 void OnDecodedPng(const std::vector<uint8_t>& rgba_data) { /* ... */ }
 
 data_decoder::mojom::PngDecoderPtr png_decoder;
@@ -301,11 +323,11 @@ directly.
 
 For convenience the Service Manager's
 [client library](https://cs.chromium.org/chromium/src/services/service_manager/public/cpp/)
-exposes two useful types: `InterfaceRegistry` and `InterfaceProvider`. These
-objects generally exist as an intertwined pair with an `InterfaceRegistry` in
+exposes two useful types: `BinderRegistry` and `InterfaceProvider`. These
+objects generally exist as an intertwined pair with a `BinderRegistry` in
 one process and a corresponding `InterfaceProvider` in another process.
 
-The `InterfaceRegistry` is essentially just a mapping from interface name
+The `BinderRegistry` is essentially just a mapping from interface name
 to binder function:
 
 ``` cpp
@@ -320,7 +342,7 @@ registry->AddInterface(base::Bind(&BindFrobinator));
 ```
 
 while an `InterfaceProvider` exposes a means of requesting interfaces from a
-remote `InterfaceRegistry`:
+remote `BinderRegistry`:
 
 ``` cpp
 mojom::FrobinatorPtr frob;
@@ -333,16 +355,14 @@ provider->GetInterface(mojo::MakeRequest(&frob));
 frob->DoTheFrobinator();
 ```
 
-For convenience, we stick an `InterfaceRegistry` and corresponding
-`InterfaceProvider` in several places at the Content layer to facilitate
-interface connection between browser and renderer processes:
+`RenderFrameHostImpl`'s binder registry corresponds to the `InterfaceProvider`
+returned by `RenderFrameImpl::GetRemoteInterfaces()`, and `RenderFrameImpl`'s
+binder registry corresponds to the `InterfaceProvider` returned by
+`RenderFrameHostImpl::GetRemoteInterfaces()`.
 
-| `InterfaceRegistry`                         | `InterfaceProvider`                        |
-|---------------------------------------------|--------------------------------------------|
-| `RenderProcessHost::GetInterfaceRegistry()` | `RenderThreadImpl::GetRemoteInterfaces()`  |
-| `RenderThreadImpl::GetInterfaceRegistry()`  | `RenderProcessHost::GetRemoteInterfaces()` |
-| `RenderFrameHost::GetInterfaceRegistry()`   | `RenderFrame::GetRemoteInterfaces()`       |
-| `RenderFrame::GetInterfaceRegistry()`       | `RenderFrameHost::GetRemoteInterfaces()`   |
+**NOTE:** this mechanism is being replaced with explicit interface factory
+approach described in [this document](
+https://docs.google.com/document/d/1e0qqv3ZGQYskE4XhtuGrYJeThjYXu8xozl7zIlwjSD0).
 
 As noted above, use of these registries is generally discouraged.
 
@@ -359,7 +379,7 @@ on the correct registry, passing a method that takes the Mojo Request object
 `mojo::MakeStrongBinding()`, `bindings_.AddBinding()`, etc). Then the class that
 needs this API can call `BindInterface()` on the connector for that process,
 e.g.
-`RenderThread::Get()->GetConnector()->BindInterface(mojom::kBrowserServiceName, std::move(&mojo_interface_))`.
+`ChildThreadImpl::current()->GetConnector()->BindInterface(mojom::kBrowserServiceName, std::move(&mojo_interface_))`.
 
 **NOTE:** `content::ServiceManagerConnection::GetForProcess()` must be called in
 the browser process on the main thread, and its connector can only be used on
@@ -371,8 +391,8 @@ Depending on what resources you need access to, the main classes are:
 
 | Renderer Class  | Corresponding Browser Class |  Explanation                                                                                                       |
 |-----------------|-----------------------------|--------------------------------------------------------------------------------------------------------------------|
-| `RenderFrame`   | `RenderFrameHost`           |  A single frame. Use this for frame-to-frame messages.                                                             |
-| `RenderView`    | `RenderViewHost`            | A view (conceptually a 'tab'). You cannot send Mojo messages to a `RenderView` directly, since frames in a tab can be in multiple processes (and the classes are deprecated). Migrate these to `RenderFrame` instead, or see section [Migrating IPC calls to `RenderView` or `RenderViewHost`](#UMigrating-IPC-calls-to-RenderView-or-RenderViewHost).  |
+| `RenderFrame`   | `RenderFrameHost`           | A single frame. Use this for frame-to-frame messages.                                                             |
+| `RenderView`    | `RenderViewHost`            | A view (conceptually a 'tab'). You cannot send Mojo messages to a `RenderView` directly, since frames in a tab can be in multiple processes (and the classes are deprecated). Migrate these to `RenderFrame` instead, or see section [Migrating IPC calls to `RenderView` or `RenderViewHost`](#other-routed-messages-to-the-browser).  |
 | `RenderProcess` | `RenderProcessHost`         | A process, containing multiple frames (probably from the same origin, but not always).                             |
 
 **NOTE:** Previously, classes that ended with `Host` were implemented on the
@@ -447,6 +467,21 @@ void Logger::BindRequest(mojom::LoggerRequest request) {
 }
 ```
 
+As you can see above, `MakeStrongBinding()` is used to lazily create an
+interface implementation when a connection is created. The lifetime of this
+implementation spans the lifetime of the connection. This is done to not
+unnecessarily create instances that might not be used.
+
+Because strong binding lifetime is not tracked or easily observable, any
+implementation bound with a strong binding must be very careful to avoid
+dependencies on things which it might outlive. As a general rule, if your
+implementation depends on any state outside of itself, please consider avoiding
+strong bindings in favor of explicit object ownership.
+
+Alternatively, the relevant registry owner class can own the implementation
+instance and dispatch the connection requests that the implementation will
+bind.
+
 #### Setting up Capabilities
 
 Once you've registered your interface, you need to add capabilities (resolved at
@@ -607,7 +642,9 @@ existing `BrowserMessageFilter` is to define a similiarly named Mojom interface
 in an inner `mojom` namespace (*e.g.,* a `content::FooMessageFilter` would have
 a corresponding `content::mojom::FooMessageFilter` interface), and have the
 `BrowserMessageFilter` implementation also implement
-`BrowserAssociatedInterface<T>`.
+`BrowserAssociatedInterface<T>` (optionally overriding methods such as
+`BrowserMessageFilter::OnDestruct()` if it needs to be deleted on a certain
+thread).
 
 Real code is probably the most useful explanation, so here are some example
 conversion CLs which demonstrate practical `BrowserAssociatedInterface` usage.
@@ -651,6 +688,10 @@ When a message is received by an interface implementation using a
 to retrieve the `RenderFrameHostImpl` targeted by the message. See the above CL
 for additional clarity.
 
+**NOTE:** When the ordering of messages doesn't matter, the `InterfaceProvider`
+of the relevant `RenderFrameHost` should be used to replace the routing ID. It
+can be obtained by calling `RenderFrame::GetRemoteInterfaces()`.
+
 ### Other Routed Messages To the Browser
 
 Other routing IDs are used when targeting either specific `RenderViewHost` or
@@ -816,9 +857,4 @@ with ideas, questions, suggestions, etc.
 :    A slightly dated but still valuable document covering some details
      regarding the conceptual mapping between legacy IPC and Mojo.
 
-[Mojo Migration Guide](https://www.chromium.org/developers/design-documents/mojo/mojo-migration-guide)
-:    Another slightly (more) data document covering the basics of IPC conversion
-     to Mojo.
-
-     TODO: The migration guide above should probably be deleted and the good
-     parts merged into this document.
+[Additional example CLs](https://docs.google.com/document/d/1GCi08AVMV96cD-tI8kW3xfRir3aNMb5U2yJFU3iAFSU)
diff --git a/chromium/ipc/ipc_logging.h b/chromium/ipc/ipc_logging.h
index eee32f62ed0..57bfb943e98 100644
--- a/chromium/ipc/ipc_logging.h
+++ b/chromium/ipc/ipc_logging.h
@@ -10,10 +10,10 @@
 #if BUILDFLAG(IPC_MESSAGE_LOG_ENABLED)
 
 #include <stdint.h>
+#include <unordered_map>
 #include <vector>
 
 #include "base/component_export.h"
-#include "base/containers/hash_tables.h"
 #include "base/memory/ref_counted.h"
 #include "base/memory/singleton.h"
 #include "base/single_thread_task_runner.h"
@@ -25,7 +25,7 @@ typedef void (*LogFunction)(std::string* name,
                             const IPC::Message* msg,
                             std::string* params);
 
-typedef base::hash_map<uint32_t, LogFunction > LogFunctionMap;
+typedef std::unordered_map<uint32_t, LogFunction> LogFunctionMap;
 
 namespace IPC {
 
diff --git a/chromium/ipc/ipc_message_start.h b/chromium/ipc/ipc_message_start.h
index 4c4c1111db9..5449491da7f 100644
--- a/chromium/ipc/ipc_message_start.h
+++ b/chromium/ipc/ipc_message_start.h
@@ -53,7 +53,7 @@ enum IPCMessageStart {
   ChromeUtilityPrintingMsgStart,
   AecDumpMsgStart,
   OzoneGpuMsgStart,
-  LayoutTestMsgStart,
+  WebTestMsgStart,
   NetworkHintsMsgStart,
   CastMediaMsgStart,
   SyncCompositorMsgStart,
diff --git a/chromium/ipc/ipc_mojo_bootstrap.cc b/chromium/ipc/ipc_mojo_bootstrap.cc
index 714603095ba..85e8d26f35b 100644
--- a/chromium/ipc/ipc_mojo_bootstrap.cc
+++ b/chromium/ipc/ipc_mojo_bootstrap.cc
@@ -146,6 +146,14 @@ class ChannelAssociatedGroupController
                    base::Unretained(this)));
     connector_->set_enforce_errors_from_incoming_receiver(false);
     connector_->SetWatcherHeapProfilerTag("IPC Channel");
+
+    // Don't let the Connector do any sort of queuing on our behalf. Individual
+    // messages bound for the IPC::ChannelProxy thread (i.e. that vast majority
+    // of messages received by this Connector) are already individually
+    // scheduled for dispatch by ChannelProxy, so Connector's normal mode of
+    // operation would only introduce a redundant scheduling step for most
+    // messages.
+    connector_->set_force_immediate_dispatch(true);
   }
 
   void Pause() {
diff --git a/chromium/ipc/ipc_sync_channel_unittest.cc b/chromium/ipc/ipc_sync_channel_unittest.cc
index f5134a5110b..a1bd7a5e50d 100644
--- a/chromium/ipc/ipc_sync_channel_unittest.cc
+++ b/chromium/ipc/ipc_sync_channel_unittest.cc
@@ -945,60 +945,6 @@ TEST_F(IPCSyncChannelTest, QueuedReply) {
 
 //------------------------------------------------------------------------------
 
-class ChattyClient : public Worker {
- public:
-  explicit ChattyClient(mojo::ScopedMessagePipeHandle channel_handle)
-      : Worker(Channel::MODE_CLIENT,
-               "chatty_client",
-               std::move(channel_handle)) {}
-
-  void OnAnswer(int* answer) override {
-    // The PostMessage limit is 10k.  Send 20% more than that.
-    const int kMessageLimit = 10000;
-    const int kMessagesToSend = kMessageLimit * 120 / 100;
-    for (int i = 0; i < kMessagesToSend; ++i) {
-      if (!SendDouble(false, true))
-        break;
-    }
-    *answer = 42;
-    Done();
-  }
-};
-
-void ChattyServer(bool pump_during_send) {
-  std::vector<Worker*> workers;
-  mojo::MessagePipe pipe;
-  workers.push_back(
-      new UnblockServer(pump_during_send, false, std::move(pipe.handle0)));
-  workers.push_back(new ChattyClient(std::move(pipe.handle1)));
-  RunTest(workers);
-}
-
-#if defined(OS_ANDROID)
-// Times out.
-#define MAYBE_ChattyServer DISABLED_ChattyServer
-#else
-#define MAYBE_ChattyServer ChattyServer
-#endif
-// Tests http://b/1093251 - that sending lots of sync messages while
-// the receiver is waiting for a sync reply does not overflow the PostMessage
-// queue.
-TEST_F(IPCSyncChannelTest, MAYBE_ChattyServer) {
-  ChattyServer(false);
-}
-
-#if defined(OS_ANDROID)
-// Times out.
-#define MAYBE_ChattyServerPumpDuringSend DISABLED_ChattyServerPumpDuringSend
-#else
-#define MAYBE_ChattyServerPumpDuringSend ChattyServerPumpDuringSend
-#endif
-TEST_F(IPCSyncChannelTest, MAYBE_ChattyServerPumpDuringSend) {
-  ChattyServer(true);
-}
-
-//------------------------------------------------------------------------------
-
 void NestedCallback(Worker* server) {
   // Sleep a bit so that we wake up after the reply has been received.
   base::PlatformThread::Sleep(base::TimeDelta::FromMilliseconds(250));
diff --git a/chromium/ipc/message_filter_router.cc b/chromium/ipc/message_filter_router.cc
index f56279eb2ed..344b83cad72 100644
--- a/chromium/ipc/message_filter_router.cc
+++ b/chromium/ipc/message_filter_router.cc
@@ -7,7 +7,7 @@
 #include <stddef.h>
 #include <stdint.h>
 
-#include "base/macros.h"
+#include "base/stl_util.h"
 #include "ipc/ipc_message_macros.h"
 #include "ipc/ipc_message_utils.h"
 #include "ipc/message_filter.h"
@@ -72,7 +72,7 @@ void MessageFilterRouter::RemoveFilter(MessageFilter* filter) {
   if (RemoveFilterImpl(global_filters_, filter))
     return;
 
-  for (size_t i = 0; i < arraysize(message_class_filters_); ++i)
+  for (size_t i = 0; i < base::size(message_class_filters_); ++i)
     RemoveFilterImpl(message_class_filters_[i], filter);
 }
 
@@ -89,7 +89,7 @@ bool MessageFilterRouter::TryFilters(const Message& message) {
 
 void MessageFilterRouter::Clear() {
   global_filters_.clear();
-  for (size_t i = 0; i < arraysize(message_class_filters_); ++i)
+  for (size_t i = 0; i < base::size(message_class_filters_); ++i)
     message_class_filters_[i].clear();
 }
 
diff --git a/chromium/ipc/run_all_perftests.cc b/chromium/ipc/run_all_perftests.cc
index b5948e1375e..b60415fd37c 100644
--- a/chromium/ipc/run_all_perftests.cc
+++ b/chromium/ipc/run_all_perftests.cc
@@ -7,10 +7,15 @@
 #include "base/command_line.h"
 #include "base/test/perf_test_suite.h"
 #include "base/test/test_io_thread.h"
+#include "build/build_config.h"
 #include "mojo/core/embedder/embedder.h"
 #include "mojo/core/embedder/scoped_ipc_support.h"
 #include "mojo/core/test/test_support_impl.h"
 
+#if defined(OS_MACOSX) && !defined(OS_IOS)
+#include "mojo/core/embedder/default_mach_broker.h"
+#endif
+
 int main(int argc, char** argv) {
   base::PerfTestSuite test(argc, argv);
 
@@ -20,6 +25,10 @@ int main(int argc, char** argv) {
       test_io_thread.task_runner(),
       mojo::core::ScopedIPCSupport::ShutdownPolicy::CLEAN);
   mojo::test::TestSupport::Init(new mojo::core::test::TestSupportImpl());
+#if defined(OS_MACOSX) && !defined(OS_IOS)
+  mojo::core::SetMachPortProvider(
+      mojo::core::DefaultMachBroker::Get()->port_provider());
+#endif
 
   return test.Run();
 }
diff --git a/chromium/ipc/sync_socket_unittest.cc b/chromium/ipc/sync_socket_unittest.cc
index f9db649a3a9..2f116a019d2 100644
--- a/chromium/ipc/sync_socket_unittest.cc
+++ b/chromium/ipc/sync_socket_unittest.cc
@@ -12,9 +12,9 @@
 
 #include "base/bind.h"
 #include "base/location.h"
-#include "base/macros.h"
 #include "base/run_loop.h"
 #include "base/single_thread_task_runner.h"
+#include "base/stl_util.h"
 #include "base/threading/thread.h"
 #include "build/build_config.h"
 #include "ipc/ipc_test_base.h"
@@ -51,7 +51,7 @@ IPC_MESSAGE_CONTROL0(MsgClassShutdown)
 namespace {
 
 const char kHelloString[] = "Hello, SyncSocket Client";
-const size_t kHelloStringLength = arraysize(kHelloString);
+const size_t kHelloStringLength = base::size(kHelloString);
 
 // The SyncSocket server listener class processes two sorts of
 // messages from the client.
@@ -226,7 +226,7 @@ TEST_F(SyncSocketTest, DisconnectTest) {
   size_t received = 1U;  // Initialize to an unexpected value.
   worker.task_runner()->PostTask(
       FROM_HERE,
-      base::Bind(&BlockingRead, &pair[0], &buf[0], arraysize(buf), &received));
+      base::Bind(&BlockingRead, &pair[0], &buf[0], base::size(buf), &received));
 
   // Wait for the worker thread to say hello.
   char hello[kHelloStringLength] = {0};