Normalize start position at the beginning of ExpandToEnclosingUnit

ExpandToEnclosingUnit for format units will call
CreatePreviousFormatStartPosition on the starting position. That method
will begin its search from the start of the node to which the position
is currently anchored. But if that position happens to be at
MaxTextOffset for its anchor, that should be treated as equivalent to
offset 0 for the next text anchor. The result is that we would
incorrectly expand the range backward if the node happened to be at a
format boundary.

The fix is to normalize the start position before doing any expansion.
I also ensured that the unit test for ExpandToEnclosingUnit covers each
of the cases enumerated in MSDN.

Bug: 928948
Change-Id: I0eda71990b69800d5464560e1a08b8f5c387b907
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1970587
Commit-Queue: Kevin Babbitt <kbabbitt@microsoft.com>
Reviewed-by: Kurt Catti-Schmidt <kschmi@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#728741}

ui/accessibility/platform/ax_platform_node_textrangeprovider_win.cc

@@ -169,6 +169,13 @@ STDMETHODIMP AXPlatformNodeTextRangeProviderWin::ExpandToEnclosingUnit(
   WIN_ACCESSIBILITY_API_HISTOGRAM(UMA_API_TEXTRANGE_EXPANDTOENCLOSINGUNIT);
   UIA_VALIDATE_TEXTRANGEPROVIDER_CALL();
 
+  // Normalize the start position so that we do not incorrectly expand it
+  // backwards if it happens to be sitting at the end of a node.
+  AXPositionInstance normalized_start =
+      start_->AsLeafTextPositionBeforeCharacter();
+  if (!normalized_start->IsNullPosition())
+    start_ = std::move(normalized_start);
+
   // Determine if start is on a boundary of the specified TextUnit, if it is
   // not, move backwards until it is. Move the end forwards from start until it
   // is on the next TextUnit boundary, if one exists.