[Bug]: Scrolling the doc adds new entry to the history dom #8669

Activity

1. keshav-bohr

   added

   bug: unconfirmed

   on Sep 21, 2026
2. akantdotgit commented on Sep 22, 2026

   

   akantdotgit

   on Sep 22, 2026

   Last edited by akantdotgit

   More actions

   Yeah, I also think so. You must have received something like this too:

   

   👍React with 👍1Reacted by Keshav Bohra
3. keshav-bohr commented on Sep 22, 2026

   

   keshav-bohr

   on Sep 22, 2026

   Author

   More actions

   Thanks for opening this! I would like to help investigate.

   Could you share:

   • Steps to reproduce
   • Expected vs actual behavior
   • Environment details

   I will take a look at the code and see if I can help.

   • Steps are already added in the initial description
   • The expected is that after scrolling, the history should not be polluted with the same page. And the actual behaviour is, as we scroll, the history keeps on adding the same page over and over again. You can see the image here, [Bug]: Scrolling the doc adds new entry to the history dom #8669 (comment)
   • Environment details: I have observed it in both chrome and safari in MacOS 27
4. akantdotgit commented on Sep 23, 2026

   

   akantdotgit

   on Sep 23, 2026

   More actions

   Found the root cause (this isn't react.dev's own code — it's in Sandpack)

   Using the Chrome DevTools Network tab, I discovered that scrolling past any embedded
   Sandpack editor triggers repeated requests to the editor's internal bundler server
   (e.g., 786946de.sandpack-bundler-4bw.pages.dev). The initiator stack trace
   for these requests points here:

   a.setLocationURLIntoIFrame @ 834.fdb5399aa041241a.js:1

   This method exists within Sandpack's SandpackRuntime class
   (@codesandbox/sandpack-client):

   setLocationURLIntoIFrame = function() {
   var url = this.options.startRoute
   ? new URL(this.options.startRoute, this.bundlerURL).toString()
   : this.bundlerURL;
   this.iframe.contentWindow?.location.replace(url);
   this.iframe.src = url; // <-- This line actually triggers the navigation
   }

   It is called every time Sandpack's internal messaging receives a "refresh"
   event:

   dispatch(e) {
   if (e.type === "refresh") this.setLocationURLIntoIFrame();
   ...
   }

   Reassigning iframe.src triggers an actual navigation for that iframe. According to the HTML spec, subframe navigations are added to the browser's joint
   session history—the same stack used by the 'Back' button and long-press history—even when the top-level page's URL never changes. This explains
   the cause of all the observed symptoms:

   • Duplicate entries without any visible URL change (navigation occurs within the iframe, not the top frame)
   • Exactly one extra entry for every scrolled Sandpack editor (8 editors → 8
     entries)
   • Recurring "allow-scripts + allow-same-origin can escape sandboxing"
     console warnings — Sandpack hardcodes both flags on every iframe it creates,
     regardless of the host site

   This appears to be a bug in Sandpack's own refresh/mount logic (perhaps the "refresh" is triggered too quickly, such as upon intersection/visibility changes) rather than a misconfiguration by react.dev. This should also be reported to codesandbox/sandpack-client, as any site embedding Sandpack in this manner would encounter the same behavior.
   And perhaps the CodeSandbox team has stopped maintaining Sandpack.

   
5. parmeetkxur commented on Oct 4, 2026

   

   parmeetkxur

   on Oct 4, 2026

   More actions

   Hi! I'd like to work on this issue. I'll first reproduce the behavior locally and investigate how the scroll/heading navigation is updating the browser history. If the issue is reproducible, I'll work on a focused fix and submit a PR.