claude-code - 💡(How to fix) Fix [BUG] Claude in Chrome: programmatic scrollTop on virtualized third-party lists triggers runaway auto-prefetch loop that hijacks the page [1 participants]

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.