diff --git a/source b/source
index 0043c75901b..17797a86de0 100644
--- a/source
+++ b/source
@@ -77035,6 +77035,20 @@ body { display:none }
    revealing algorithm</span> on <var>node</var>.</p></li>
   </ol>
 
+  <p class="warning">
+  <!--INSERT TRACKING-->
+  When find-in-page auto-expands a <code>details</code> element like this, it will fire a <code
+  data-x="event-toggle">toggle</code> event. As with the separate <code
+  data-x="event-scroll">scroll</code> event that find-in-page fires, this event could be used by the
+  page to discover what the user is typing into the find-in-page dialog. If the page creates a tiny
+  scrollable area with the current search term and every possible next character the user could type
+  separated by a gap, and observes which one the browser scrolls to, it can add that character to
+  the search term and update the scrollable area to incrementally build the search term. By wrapping
+  each possible next match in a closed <code>details</code> element, the page could listen to <code
+  data-x="event-toggle">toggle</code> events instead of <code data-x="event-scroll">scroll</code>
+  events. This attack could be addressed for both events by not acting on every character the user
+  types into the find-in-page dialog.</p>
+
   <h4>Interaction with selection</h4>
 
   <p>The find-in-page process is invoked in the context of a document, and may have an effect on