[BUG] Claude in Chrome: programmatic scrollTop on virtualized third-party lists triggers runaway auto-prefetch loop that hijacks the page

Resolved 💬 1 comment Opened Apr 25, 2026 by keitotatsuguchi Closed May 29, 2026

Description

When mcp__claude-in-chrome__javascript_tool sets element.scrollTop programmatically multiple times on a virtualized scroll container in a third-party page (in this case Midjourney's alpha.midjourney.com/imagine Today gallery), the page enters a runaway auto-prefetch / scroll-restore loop that:

  • Continues scrolling autonomously after the user JS function has fully completed
  • Increases scrollTop by ~800px every 500ms indefinitely
  • Ignores subsequent element.scrollTop = 0 resets (the host page's React / virtualization layer immediately re-applies a deeper position)
  • Loads thousands of past items into the DOM (scrollHeight grew from ~12K to 1,885,089 during the runaway)

The only way I found to recover is to navigate the tab to the same URL (full reload). All window.* state is lost in the process.

Reproduction

  1. Open https://alpha.midjourney.com/imagine in a Chrome MCP-connected tab (logged in)
  2. Via mcp__claude-in-chrome__javascript_tool, run something like:
(async () => {
  const sc = Array.from(document.querySelectorAll('*')).find(el => {
    const cs = getComputedStyle(el);
    return cs.overflowY === 'scroll' && el.scrollHeight > el.clientHeight + 10;
  });
  let curr = 0;
  while (curr <= 12000) {
    sc.scrollTop = curr;
    await new Promise(r => setTimeout(r, 200));
    curr += 400;
  }
})();
  1. The async function completes in ~6 seconds, but the page keeps scrolling on its own afterwards.

Diagnostic snapshot (taken after the user function had already returned)

{
  "before": 791600,
  "after500ms": 792400,        // moved +800 with no user script running
  "movedAuto": true,
  "afterForceTop": 792800,     // setting scrollTop = 0 was ignored
  "after500msMore": 793600,
  "scrollHeight": 1885089
}

Brute-force clearInterval(i); clearTimeout(i) for i in [0, 10000) had no effect. Only mcp__claude-in-chrome__navigate to the same URL stopped it.

Environment

  • macOS Darwin 24.6.0
  • Chrome (current as of 2026-04-25)
  • Target page: https://alpha.midjourney.com/imagine (React-based virtualized infinite list)
  • Claude Code with the Claude in Chrome extension

Impact

For automation that needs to scan a virtualized gallery (Midjourney's Today section in my case), anything beyond a single one-shot scroll becomes unsafe. Repeated programmatic scrollTop writes can soft-lock the host page mid-task and force a reload that loses any non-persisted window.* state. This effectively prevents reliable DOM scans on virtualized third-party pages.

Suggested fixes / docs

  • Document this hazard in the javascript_tool docs (third-party virtualized lists + programmatic scroll = potential runaway)
  • Optionally provide a higher-level helper that performs batched scroll-based DOM scans without leaving the host page in a runaway state
  • For virtualization-heavy targets, recommend using the page's internal data API (when one is available) instead of DOM scraping

Workaround

Reload the tab via mcp__claude-in-chrome__navigate to the same URL. Plan for any window.* state to be lost — persist anything important to a file (e.g. via a local save server) before triggering scroll-based scans.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗