That commit is the issue. Defining a static function in //components and implementing it in //chrome is an anti-pattern; if there's a need for dependency injection, it should be done explicitly (e.g. by taking in a callback from the embedder or something). In this case components_unittests is failing to compile because there's no definition for the static function in that target. The reason that only some builds are failing with this error is that analyze.py skips building components_unittests for CLs that don't affect it.

I'm going to try reverting the CL as the approach here needs to be rethought.

https://chromium-review.googlesource.com/c/chromium/src/+/941161 is going through the CQ now.

The revert landed, so the compile issue should be fixed. Leaving the bug open as it has useful info for what will be needed to reland this functionality.

It looks like we missed adding this kind of stub: <https://cs.chromium.org/chromium/src/components/constrained_window/test_create_native_web_modal_manager_cocoa.cc?type=cs&q=CreateNativeWebModalManager&l=10>

blundell@: I agree that it's an anti-pattern, but it's already done here: <https://cs.chromium.org/chromium/src/components/web_modal/web_contents_modal_dialog_manager.h?type=cs&q=CreateNativeWebModalManager&l=36>. Perhaps we can do something with WebContentsModalDialogManagerDelegate instead (?).

ellyjones@: That one should also be fixed :). Apart from any issue about these kinds of compile failures, having static functions that are implemented in the embedder is a requirement on the embedder that would be invisible to new embedders looking to use the component. There should be some way to hook in either via a delegate or just by passing state into //components-level functions/objects from //chrome explicitly.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f9f3bc00ce408ccf0e08aed82d68fb6a77c016a8

commit f9f3bc00ce408ccf0e08aed82d68fb6a77c016a8
Author: Leonard Grey <lgrey@chromium.org>
Date: Tue Mar 06 16:50:53 2018

[Mac] Move Polychrome feature to ui/base

This is needed because ShowModal needs to know if a Polychrome browser
is in Views or Cocoa, and it live in components/, which can't depend on
chrome/

This leaves the views_mode_controller version of |IsViewsBrowserCocoa|
in place to avoid changing all its callers.

Bug:  817302 
Change-Id: Ia8e06927410fb9aad3fe696a2446418b4d115a7c
Reviewed-on: https://chromium-review.googlesource.com/949362
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541125}
[modify] https://crrev.com/f9f3bc00ce408ccf0e08aed82d68fb6a77c016a8/chrome/browser/ui/views_mode_controller.cc
[modify] https://crrev.com/f9f3bc00ce408ccf0e08aed82d68fb6a77c016a8/chrome/common/chrome_features.cc
[modify] https://crrev.com/f9f3bc00ce408ccf0e08aed82d68fb6a77c016a8/chrome/common/chrome_features.h
[modify] https://crrev.com/f9f3bc00ce408ccf0e08aed82d68fb6a77c016a8/ui/base/ui_base_features.cc
[modify] https://crrev.com/f9f3bc00ce408ccf0e08aed82d68fb6a77c016a8/ui/base/ui_base_features.h

ooh neat - that will help fix  Issue 798944  as well