basalt-win32 0.0.0-rc5

package/native/tests/test_win32_titlebar.cpp

@@ -0,0 +1,111 @@
+// The geometry of a hidden title bar: how big the caption is, which button a
+// point is over, and whether a point drags the window.
+//
+// Pure functions of a view tree and a size, so no window, no DWM and no React
+// Native. These are the questions a custom caption gets wrong in ways a person
+// notices at once -- a close button a few pixels off, a label that will not
+// drag, a button that drags instead of pressing -- and a test does not, unless
+// it asks them.
+
+#include "TestHarness.h"
+
+#include "RnWin32View.h"
+#include "Win32TitleBarLayout.h"
+
+#include <memory>
+#include <sstream>
+#include <string>
+#include <vector>
+
+using basalt::win32::CaptionButton;
+using basalt::win32::captionButtonAt;
+using basalt::win32::captionMetricsForDpi;
+using basalt::win32::isTitleBarDragRegionAt;
+using basalt::win32::kTitleBarDragRegionId;
+using basalt::win32::kTitleBarNoDragRegionId;
+using basalt::win32::RnWin32View;
+
+namespace {
+
+class Tree {
+ public:
+  RnWin32View *box(int32_t tag, float x, float y, float w, float h, const char *nativeId = "") {
+    auto view = std::make_unique<RnWin32View>(tag);
+    view->setFrame(x, y, w, h);
+    view->setNativeId(nativeId);
+    RnWin32View *raw = view.get();
+    views_.push_back(std::move(view));
+    return raw;
+  }
+
+ private:
+  std::vector<std::unique_ptr<RnWin32View>> views_;
+};
+
+} // namespace
+
+TEST(caption_metrics_are_windows_elevens_and_scale_with_dpi) {
+  const auto at100 = captionMetricsForDpi(96);
+  EXPECT_NEAR(at100.height, 32.0f, 0.01f);
+  EXPECT_NEAR(at100.buttonWidth, 46.0f, 0.01f);
+
+  const auto at150 = captionMetricsForDpi(144);
+  EXPECT_NEAR(at150.height, 48.0f, 0.01f);
+  EXPECT_NEAR(at150.buttonWidth, 69.0f, 0.01f);
+
+  // A DPI of zero is what a window that has not been shown can report; it is
+  // treated as 96 rather than collapsing the caption to nothing.
+  EXPECT_NEAR(captionMetricsForDpi(0).height, 32.0f, 0.01f);
+}
+
+TEST(caption_buttons_sit_flush_right_in_the_order_windows_puts_them) {
+  const auto metrics = captionMetricsForDpi(96);
+  const float width = 800;
+
+  EXPECT(captionButtonAt(799, 10, width, metrics) == CaptionButton::Close);
+  EXPECT(captionButtonAt(width - 46 - 1, 10, width, metrics) == CaptionButton::Maximize);
+  EXPECT(captionButtonAt(width - 92 - 1, 10, width, metrics) == CaptionButton::Minimize);
+  EXPECT(captionButtonAt(width - 138 - 1, 10, width, metrics) == CaptionButton::None);
+
+  // Below the caption, or outside the window, is no button at all.
+  EXPECT(captionButtonAt(799, 32, width, metrics) == CaptionButton::None);
+  EXPECT(captionButtonAt(-1, 10, width, metrics) == CaptionButton::None);
+}
+
+TEST(a_label_inside_a_drag_region_drags_the_window) {
+  Tree tree;
+  RnWin32View *root = tree.box(1, 0, 0, 800, 600);
+  RnWin32View *header = tree.box(2, 0, 0, 800, 32, kTitleBarDragRegionId);
+  root->insertChild(header, 0);
+  header->insertChild(tree.box(3, 10, 5, 100, 20), 0);
+
+  EXPECT(isTitleBarDragRegionAt(root, 20, 10));
+  EXPECT(isTitleBarDragRegionAt(root, 400, 10));
+}
+
+TEST(a_no_drag_region_inside_a_drag_region_stays_pressable) {
+  Tree tree;
+  RnWin32View *root = tree.box(1, 0, 0, 800, 600);
+  RnWin32View *header = tree.box(2, 0, 0, 800, 32, kTitleBarDragRegionId);
+  root->insertChild(header, 0);
+  RnWin32View *button = tree.box(3, 600, 0, 50, 32, kTitleBarNoDragRegionId);
+  header->insertChild(button, 0);
+
+  EXPECT(!isTitleBarDragRegionAt(root, 620, 10));
+
+  // And a drag region nested inside that button drags again: the nearest
+  // marker decides, not the outermost.
+  button->insertChild(tree.box(4, 5, 5, 10, 10, kTitleBarDragRegionId), 0);
+  EXPECT(isTitleBarDragRegionAt(root, 607, 7));
+}
+
+TEST(a_point_under_nothing_marked_is_ordinary_client_area) {
+  Tree tree;
+  RnWin32View *root = tree.box(1, 0, 0, 800, 600);
+  root->insertChild(tree.box(2, 0, 0, 800, 32, kTitleBarDragRegionId), 0);
+  root->insertChild(tree.box(3, 0, 32, 800, 568), 1);
+
+  EXPECT(!isTitleBarDragRegionAt(root, 400, 300));
+  // A miss altogether -- outside the root -- is not a drag either.
+  EXPECT(!isTitleBarDragRegionAt(root, 900, 10));
+}

package/native/tests/test_win32_titlebar_actions.cpp

@@ -0,0 +1,62 @@
+// The caption's four actions before there is a window.
+//
+// minimize, toggleMaximize, close and startWindowDrag are what an app-drawn
+// header asks for by name. GtkWindowModule and AppKitWindowModule have
+// registered them all along; this host registered none of them, so on Windows
+// useWindow().minimize() and .close() were silent no-ops -- and useCloseRequest
+// could refuse a close and then find that agreeing to it did nothing either.
+//
+// Now that they are registered, the question this asks is the one a test can
+// answer without a desktop: what they do before the host has an HWND. An app
+// can call close() from its first render, and the honest answer then is to do
+// nothing, not to dereference a null window.
+//
+// What this deliberately cannot check is the other half -- that a real window
+// actually minimises, or that startDrag hands Windows its move loop. Both need
+// a window, a message queue and a person's mouse; they belong to the
+// end-to-end suite, and saying so here is better than a test that looks like
+// it covers them.
+//
+// Lives in the React-Native-gated source list rather than beside
+// test_win32_titlebar.cpp, because Win32TitleBar is compiled into
+// basalt_win32_mounting, which only exists when basalt_core does. Its
+// neighbour tests pure geometry and needs no such thing.
+
+#include "TestHarness.h"
+
+#include "Win32TitleBar.h"
+
+using basalt::TitleBarStyle;
+using basalt::Win32TitleBar;
+
+TEST(caption_actions_do_nothing_when_no_window_is_attached) {
+  Win32TitleBar bar;
+  const TitleBarStyle before = bar.style();
+
+  bar.minimize();
+  bar.toggleMaximize();
+  bar.close();
+  bar.startDrag();
+
+  // Reaching this line is most of the assertion: each call returned rather
+  // than posting to a null window. The style is the one piece of state they
+  // could have disturbed on the way, so it is worth saying it did not move.
+  EXPECT(bar.style() == before);
+}
+
+TEST(caption_actions_are_repeatable_without_a_window) {
+  Win32TitleBar bar;
+
+  // Twice, because the guard is a plain early return and an app that polls --
+  // a header re-rendering on every frame, say -- makes exactly this call
+  // pattern. Nothing here accumulates state, and this is what would notice if
+  // one of them started to.
+  for (int attempt = 0; attempt < 2; ++attempt) {
+    bar.minimize();
+    bar.toggleMaximize();
+    bar.close();
+    bar.startDrag();
+  }
+
+  EXPECT(bar.style() == TitleBarStyle::Native);
+}

package/native/tests/test_win32_view.cpp

@@ -0,0 +1,222 @@
+// Tests for the Windows view layer.
+//
+// RnWin32View has no React Native dependency and no Direct2D dependency until
+// something paints, so these need no Fabric machinery, no window and no
+// display. They share the toolkit-free harness the GTK and macOS suites use.
+//
+// The questions are deliberately the same ones tests/test_view.cpp asks of GTK
+// and tests/test_appkit_view.mm asks of AppKit, in the same order: what is being
+// checked is largely whether three platforms still agree, so a divergence
+// should fail here rather than in an app.
+
+#include "TestHarness.h"
+
+#include "RnWin32View.h"
+
+#include <memory>
+#include <sstream>
+#include <string>
+#include <vector>
+
+using basalt::win32::RnWin32View;
+
+namespace {
+
+// The tests own their views, as the mounting registry will. A view owns neither
+// its children nor its parent; see RnWin32View.h.
+class Tree {
+ public:
+  RnWin32View *box(int32_t tag, float x, float y, float w, float h) {
+    auto view = std::make_unique<RnWin32View>(tag);
+    view->setFrame(x, y, w, h);
+    RnWin32View *raw = view.get();
+    views_.push_back(std::move(view));
+    return raw;
+  }
+
+  // Releases one view, the way a Delete mutation would.
+  void destroy(RnWin32View *view) {
+    for (auto it = views_.begin(); it != views_.end(); ++it) {
+      if (it->get() == view) {
+        views_.erase(it);
+        return;
+      }
+    }
+  }
+
+ private:
+  std::vector<std::unique_ptr<RnWin32View>> views_;
+};
+
+int32_t tagOfChild(const RnWin32View *parent, size_t index) {
+  return parent->children()[index]->tag();
+}
+
+} // namespace
+
+TEST(win32_view_stores_its_tag_and_frame) {
+  Tree tree;
+  RnWin32View *view = tree.box(42, 12, 34, 100, 50);
+
+  EXPECT_EQ(view->tag(), 42);
+  EXPECT_NEAR(view->frame().x, 12.0, 0.001);
+  EXPECT_NEAR(view->frame().y, 34.0, 0.001);
+  EXPECT_NEAR(view->frame().width, 100.0, 0.001);
+  EXPECT_NEAR(view->frame().height, 50.0, 0.001);
+}
+
+TEST(win32_children_insert_at_the_requested_index) {
+  Tree tree;
+  RnWin32View *root = tree.box(1, 0, 0, 200, 200);
+  RnWin32View *first = tree.box(2, 0, 0, 10, 10);
+  RnWin32View *second = tree.box(3, 0, 0, 10, 10);
+  RnWin32View *between = tree.box(4, 0, 0, 10, 10);
+
+  root->insertChild(first, 0);
+  root->insertChild(second, 1);
+  // An Insert's index counts positions in the parent's *final* child list, so
+  // this lands between the two. An append-only implementation passes every
+  // other test in this file.
+  root->insertChild(between, 1);
+
+  EXPECT_EQ(root->children().size(), size_t{3});
+  EXPECT_EQ(tagOfChild(root, 0), 2);
+  EXPECT_EQ(tagOfChild(root, 1), 4);
+  EXPECT_EQ(tagOfChild(root, 2), 3);
+}
+
+TEST(win32_view_removes_only_its_own_child) {
+  Tree tree;
+  RnWin32View *root = tree.box(1, 0, 0, 200, 200);
+  RnWin32View *mine = tree.box(2, 0, 0, 10, 10);
+  RnWin32View *someone_elses = tree.box(3, 0, 0, 10, 10);
+  RnWin32View *other = tree.box(4, 0, 0, 200, 200);
+
+  root->insertChild(mine, 0);
+  other->insertChild(someone_elses, 0);
+
+  root->removeChild(someone_elses);
+
+  EXPECT_EQ(root->children().size(), size_t{1});
+  EXPECT_EQ(other->children().size(), size_t{1});
+  EXPECT_EQ(someone_elses->parent()->tag(), 4);
+}
+
+TEST(win32_remove_detaches_but_does_not_destroy) {
+  Tree tree;
+  RnWin32View *root = tree.box(1, 0, 0, 200, 200);
+  RnWin32View *child = tree.box(2, 5, 5, 10, 10);
+
+  root->insertChild(child, 0);
+  root->removeChild(child);
+
+  // A reparent is a Remove and an Insert with no Delete between them, so the
+  // view has to survive the gap with everything about it intact.
+  EXPECT_EQ(root->children().size(), size_t{0});
+  EXPECT(child->parent() == nullptr);
+  EXPECT_NEAR(child->frame().x, 5.0, 0.001);
+}
+
+TEST(win32_insert_reparents_without_a_remove) {
+  Tree tree;
+  RnWin32View *first = tree.box(1, 0, 0, 200, 200);
+  RnWin32View *second = tree.box(2, 0, 0, 200, 200);
+  RnWin32View *child = tree.box(3, 0, 0, 10, 10);
+
+  first->insertChild(child, 0);
+  second->insertChild(child, 0);
+
+  EXPECT_EQ(first->children().size(), size_t{0});
+  EXPECT_EQ(second->children().size(), size_t{1});
+  EXPECT_EQ(child->parent()->tag(), 2);
+}
+
+TEST(win32_destroying_a_view_leaves_nothing_pointing_at_it) {
+  Tree tree;
+  RnWin32View *root = tree.box(1, 0, 0, 200, 200);
+  RnWin32View *child = tree.box(2, 0, 0, 10, 10);
+  RnWin32View *grandchild = tree.box(3, 0, 0, 5, 5);
+
+  root->insertChild(child, 0);
+  child->insertChild(grandchild, 0);
+
+  tree.destroy(child);
+
+  // The registry owns every view, so a Delete of a parent does not delete its
+  // children -- their own Deletes are separate mutations. What must not survive
+  // is a pointer to the freed view, on either side.
+  EXPECT_EQ(root->children().size(), size_t{0});
+  EXPECT(grandchild->parent() == nullptr);
+}
+
+TEST(win32_z_index_reorders_painting_and_not_the_child_list) {
+  Tree tree;
+  RnWin32View *root = tree.box(1, 0, 0, 200, 200);
+  RnWin32View *first = tree.box(2, 0, 0, 10, 10);
+  RnWin32View *second = tree.box(3, 0, 0, 10, 10);
+
+  root->insertChild(first, 0);
+  root->insertChild(second, 1);
+  first->setZIndex(10);
+
+  // Fabric's Insert and Remove index into this list, so it stays in mutation
+  // order no matter what zIndex says. That painting follows zIndex instead is
+  // asserted in test_win32_paint.cpp, where it can be seen.
+  EXPECT_EQ(tagOfChild(root, 0), 2);
+  EXPECT_EQ(tagOfChild(root, 1), 3);
+}
+
+TEST(win32_scroll_offset_is_reported_in_the_tree) {
+  Tree tree;
+  RnWin32View *root = tree.box(1, 0, 0, 200, 200);
+  root->setScrollOffset(0, 40);
+
+  const std::string described = root->describeTree();
+  EXPECT_EQ(described, std::string("view tag=1 frame=(0,0 200x200) scroll=(0,40)\n"));
+}
+
+TEST(win32_transform_reports_the_affine_part_of_matrix3d) {
+  Tree tree;
+  RnWin32View *root = tree.box(1, 0, 0, 200, 200);
+
+  // A quarter turn with a translation, in CSS matrix3d order, which is column
+  // major: elements 0, 1, 4, 5, 12 and 13 are the affine part. Getting the
+  // indices wrong is a transpose, and a transpose is invisible on any
+  // axis-aligned box -- which is why this asserts on an asymmetric matrix.
+  const float matrix[16] = {
+      0, 1, 0, 0, //
+      -1, 0, 0, 0, //
+      0, 0, 1, 0, //
+      5, 7, 0, 1};
+  root->setTransform(matrix);
+
+  const std::string described = root->describeTree();
+  EXPECT_EQ(described,
+            std::string("view tag=1 frame=(0,0 200x200) transform=(0,1,-1,0,5,7)\n"));
+
+  root->setTransform(nullptr);
+  EXPECT_EQ(root->describeTree(), std::string("view tag=1 frame=(0,0 200x200)\n"));
+}
+
+TEST(win32_view_describes_its_tree_like_the_other_hosts) {
+  Tree tree;
+  RnWin32View *root = tree.box(1, 0, 0, 640, 420);
+  root->setBackgroundColor(0.12f, 0.13f, 0.16f, 1.0f, true);
+
+  RnWin32View *child = tree.box(2, 32, 32, 240, 160);
+  child->setOpacity(0.4f);
+  child->setClipsChildren(true);
+  root->insertChild(child, 0);
+
+  // Byte for byte what tests/test_appkit_view.mm expects of AppKit and what
+  // gtk/RnView.cpp produces. scripts/compare_hosts.sh diffs these dumps line by
+  // line, so this string is the contract rather than a convenience.
+  const std::string expected =
+      "view tag=1 frame=(0,0 640x420) bg=#1f2129ff\n"
+      "  view tag=2 frame=(32,32 240x160) opacity=0.4 clip\n";
+  EXPECT_EQ(root->describeTree(), expected);
+}
+
+int main(int argc, char **argv) {
+  return basalt::testing::runAllTests(argc, argv);
+}

package/native/win32/ColorSchemeWin32.cpp

@@ -0,0 +1,56 @@
+// Windows' half of core/ColorScheme.h -- light or dark, as the system has it.
+//
+// The answer lives in the registry rather than in an API: Windows exposes the
+// app theme as `AppsUseLightTheme` under the Personalize key, and there is no
+// Win32 function that returns it. WinRT has UISettings, which would be a
+// heavier dependency for one boolean and is unavailable in a plain Win32
+// process without an apartment. The registry value is what every desktop
+// framework reads, and it is what Explorer writes when the setting changes.
+//
+// Note the sense: the value is "apps use *light* theme", so 1 is light and 0 is
+// dark, and an absent value means light -- which is the pre-2018 behaviour and
+// still the right default.
+
+#include "ColorScheme.h"
+
+#include <windows.h>
+
+namespace basalt {
+namespace {
+
+constexpr const wchar_t *kPersonalizeKey =
+    L"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Themes\\Personalize";
+constexpr const wchar_t *kAppsUseLightTheme = L"AppsUseLightTheme";
+
+} // namespace
+
+ColorScheme systemColorScheme() {
+  DWORD value = 1;
+  DWORD size = sizeof(value);
+  const LSTATUS status = RegGetValueW(HKEY_CURRENT_USER,
+                                      kPersonalizeKey,
+                                      kAppsUseLightTheme,
+                                      RRF_RT_REG_DWORD,
+                                      nullptr,
+                                      &value,
+                                      &size);
+  if (status != ERROR_SUCCESS) {
+    // No value at all: a machine that predates the setting, or a policy that
+    // removed it. Light is what those show.
+    return ColorScheme::Light;
+  }
+  return value == 0 ? ColorScheme::Dark : ColorScheme::Light;
+}
+
+void startObservingColorScheme() {
+  // Not implemented, and deliberately not faked. Watching this properly means
+  // RegNotifyChangeKeyValue on a worker thread, or handling WM_SETTINGCHANGE
+  // with lParam "ImmersiveColorSet" on the host's window -- and the second is
+  // the better answer, because it arrives on the thread that would have to
+  // repaint. It belongs with the host for that reason.
+  //
+  // The other two desktops subscribe and, per docs/BACKLOG.md, have never been
+  // watched firing. So nothing is lost here that is proven to work there.
+}
+
+} // namespace basalt

package/native/win32/ComponentRegistryWin32.cpp

@@ -0,0 +1,124 @@
+// Which components this platform claims.
+//
+// `getDefaultComponentRegistryFactory()` is declared by ReactCommon and defined
+// nowhere in it: each host supplies its own and, in doing so, says what it can
+// put on screen. Phase 19 found out the hard way that it cannot be shared --
+// `ParagraphComponentDescriptor` constructs a `TextLayoutManager`, so a
+// platform without a text engine fails to link rather than failing to render
+// text. See `core/ComponentRegistry.h`.
+//
+// The set here must match what `Win32MountingManager::hasComponent` answers
+// for. When they disagree the registry wins, Fabric builds shadow nodes nothing
+// can mount, and the app renders blank rectangles rather than reporting
+// anything -- which is why the two live in the same directory and should be
+// read together.
+
+#include "ComponentRegistry.h"
+
+#include <react/renderer/componentregistry/ComponentDescriptorProviderRegistry.h>
+#include <react/renderer/components/FBReactNativeSpec/ComponentDescriptors.h>
+#include <react/renderer/components/image/ImageComponentDescriptor.h>
+#include <react/renderer/components/iostextinput/TextInputComponentDescriptor.h>
+#include <react/renderer/components/modal/ModalHostViewComponentDescriptor.h>
+#include <react/renderer/components/scrollview/ScrollViewComponentDescriptor.h>
+#include <react/renderer/components/switch/AppleSwitchComponentDescriptor.h>
+#include <react/renderer/components/text/ParagraphComponentDescriptor.h>
+#include <react/renderer/components/text/RawTextComponentDescriptor.h>
+#include <react/renderer/components/text/TextComponentDescriptor.h>
+#include <react/renderer/components/view/ViewComponentDescriptor.h>
+
+namespace facebook::react {
+
+ComponentRegistryFactory getDefaultComponentRegistryFactory() {
+  return [](const EventDispatcher::Weak &eventDispatcher,
+            const std::shared_ptr<const ContextContainer> &contextContainer) {
+    static auto providerRegistry = []() {
+      auto registry = std::make_shared<ComponentDescriptorProviderRegistry>();
+      registry->add(concreteComponentDescriptorProvider<ViewComponentDescriptor>());
+
+      // Text is three descriptors and only one of them mounts. <Text> becomes a
+      // Text node, its string a RawText node, and the outermost <Text> a
+      // Paragraph that folds the whole subtree into a single AttributedString.
+      registry->add(concreteComponentDescriptorProvider<ParagraphComponentDescriptor>());
+      registry->add(concreteComponentDescriptorProvider<TextComponentDescriptor>());
+      registry->add(concreteComponentDescriptorProvider<RawTextComponentDescriptor>());
+
+      // Image's descriptor pulls an ImageManager out of the ContextContainer,
+      // creating one if absent. React Native's cxx ImageManager is a stub, so
+      // it produces no pixels; the mounting manager loads them from the props,
+      // which is what Android does too.
+      registry->add(concreteComponentDescriptorProvider<ImageComponentDescriptor>());
+
+      // ScrollView's content child arrives as "ScrollContentView", which
+      // React Native's own registry rewrites to "View" before it reaches here,
+      // so it needs no entry of its own. What the descriptor is really for is
+      // ScrollViewState: without it the substituted UnimplementedNativeView has
+      // nowhere to keep a content offset, so a ScrollView renders and never
+      // scrolls -- silently, which is why the absence used to be worth naming.
+      registry->add(concreteComponentDescriptorProvider<ScrollViewComponentDescriptor>());
+
+      // React Native's *iOS* TextInput, whose shadow node, props, state and
+      // event emitter are pure C++ and measure through a TextLayoutManager --
+      // the DirectWrite one, here. Android's variant includes fbjni and calls
+      // into a Java FabricUIManager, so it cannot be used outside an Android
+      // build. Both other desktops made the same choice; see
+      // docs/DECISIONS.md. Its component name is "TextInput", which is what
+      // React Native's own componentNameByReactViewName maps
+      // RCTSinglelineTextInputView to, so nothing here renames anything.
+      registry->add(concreteComponentDescriptorProvider<TextInputComponentDescriptor>());
+
+      // Deliberately absent, and the absence is a decision rather than an
+      // oversight: ExpoImage's seam exists in core/ExpoImageComponent.h and its
+      // props class is portable, but nothing here mounts one yet.
+      //
+      // See docs/BACKLOG.md.
+
+      // --- The controls -----------------------------------------------------
+      //
+      // Everything above is a box with something drawn in it. These are not:
+      // each one is a toolkit control, or a window, and each one needed the
+      // view layer to grow a peer before registering it here would have meant
+      // anything. Registering a descriptor with nothing to mount it does not
+      // error -- Fabric builds the shadow nodes, lays them out, and the app
+      // renders blank rectangles -- so this list and the mounting manager's
+      // `hasComponent` are two statements of the same fact and have to agree.
+
+      // <ActivityIndicator>. React Native's JavaScript writes the 20pt or 36pt
+      // box into the view's style, so the shadow node needs no measurement of
+      // its own; what the host draws inside it is a spinner.
+      registry->add(concreteComponentDescriptorProvider<ActivityIndicatorViewComponentDescriptor>());
+      // <Switch>. The descriptor is React Native's iOS one -- portable C++
+      // apart from a `measureContent` that instantiates a UISwitch, which
+      // core/DesktopControls.cpp replaces with a constant so a switch is the
+      // same size on all three desktops.
+      registry->add(concreteComponentDescriptorProvider<SwitchComponentDescriptor>());
+      // <Modal>. Not a second window: the shadow node is a root-kind node sized
+      // from its state and positioned absolutely, so a modal is an overlay
+      // filling the surface -- which is also what it is on the web. The host
+      // commits the window's size into that state; see
+      // core/DesktopControls.h's modalScreenSizeNeedsUpdate for why it must.
+      registry->add(concreteComponentDescriptorProvider<ModalHostViewComponentDescriptor>());
+      // <RefreshControl>. The spinner a scroll view shows while it refreshes.
+      // The gesture that starts it is in core/PullToRefresh.h, because a
+      // desktop has no rubber band to release.
+      registry->add(concreteComponentDescriptorProvider<PullToRefreshViewComponentDescriptor>());
+      // What React Native substitutes for a component no platform registered.
+      // Registering it is what turns "nothing happens" into a mounted view the
+      // tree dump can show, and it is what the comments above mean when they
+      // say the substitution is silent.
+      registry->add(concreteComponentDescriptorProvider<UnimplementedNativeViewComponentDescriptor>());
+      // React DevTools' element highlighter. It draws nothing here yet -- the
+      // highlight arrives as a command rather than as props -- but a DevTools
+      // session mounts one, and an unregistered component in the tree is a
+      // blank rectangle in the middle of the app.
+      registry->add(concreteComponentDescriptorProvider<DebuggingOverlayComponentDescriptor>());
+
+      return registry;
+    }();
+
+    return providerRegistry->createComponentDescriptorRegistry(
+        {eventDispatcher, contextContainer, nullptr});
+  };
+}
+
+} // namespace facebook::react