Update speed-metrics-changelog with the information for m133 INP launch.

Document EventTimingSelectionAutoScrollNoInteractionId change.

Change-Id: Ic2ceb056941f7780445f8c3ddc4f1fe05dcdd37b
Bug: 330711100
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6309045
Commit-Queue: Michal Mocny <mmocny@chromium.org>
Reviewed-by: Annie Sullivan <sullivan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1426305}

docs/speed/metrics_changelog/2025_02_inp.md

@@ -0,0 +1,59 @@
+# Interaction to Next Paint Changes in Chrome 133
+
+## Enable EventTimingSelectionAutoScrollNoInteractionId by default
+
+Typically, highlighting text on a page with a pointing device does count as an
+interaction, will get reported with interactionID and will count towards INP.
+
+This is because long tasks on the page will prevent the highlighted area from
+updating, and a site will certainly feel unresponsive to users.
+
+At the moment, Event Timing will only measure the first pointerdown, and final
+pointerup, gestures of these types of interactions.  Pointermove events in the
+middle, although they might update highlighted area and may feel slow, are
+never measured.
+
+This feature which is launching updates one specific use case we learned should
+not warrant being labelled an Event Timing interaction: when the highlighted
+area goes beyond the viewport boundary, and updates force the page to scroll
+automatically.  At this point, this becomes a "scrolling" interaction, which
+Event Timing ignores under typical flows.
+
+Although technically still a pointer interaction, and although highlighted area
+is still being updated, Scrolling has very different characteristics than other
+interactions:
+
+- Smoothness and consistency across many animation frames, rather than
+responsiveness of a single frame, matter more
+- Scrolling is typically driven by the compositor thread, without the need for
+main thread scheduling.  The "default action" of scrolling produces a "next
+paint" before the event is dispatched and measured by Event Timing.  Thus even a
+slow event timing might still feel fast to the user because of the immediate
+scroll offset update.
+- Finally, at scroll end many effects might trigger, such as intersection
+observers or lazy loaded content, which can slow down the pointerup event.
+
+Note: this experiment was first landed in Chrome 132:
+[Reland "Flush event timings at visibility change"](https://chromium-review.googlesource.com/c/chromium/src/+/5719352), and was slowly rolled out.
+
+### How does this affect a site's metrics?
+
+In practice, it shouldn't affect most sites at all.  Most sites will never
+even have a chance to be affected by this change, and for those that might, it
+is unlikely to affect your high percentile field data.
+
+However, for the few sites which have the following patterns:
+
+- Users are often highlighting enough text to scroll the page (i.e. perhaps
+on desktop devices, with long articles)
+- Effects trigger during scroll or after stop (i.e. scroll linked animations,
+which require main thread, or intersection observers + lazy loaded content)
+- Long tasks that trigger from these effects
+
+Under criteria such as these, you might have a long interaction triggered by a
+pointerup event which also immediately stop the scroll of the page.
+
+### When were users affected?
+
+Launch was the week of Feb 27, 2025, when m133 was in stable, but a limited
+number of early adopters might have seen this change as early as m132.

docs/speed/metrics_changelog/inp.md

@@ -2,6 +2,8 @@
 
 This is a list of changes to [Interaction to Next Paint](https://web.dev/inp).
 
+* Chrome 133
+  * Launch feature: [Enable EventTimingSelectionAutoScrollNoInteractionId by default](2025_02_inp.md)
 * Chrome 130
   * Launch feature: [Enable EventTimingTapStopScrollNoInteractionId by default](2024_10_inp.md)
   * Launch feature: [Enable EventTimingHandleKeyboardEventSimulatedClick by default](2024_10_inp.md)