Shared canvases do not scroll in the browser

Support Bug Reports
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

A shared canvas opened in a browser (Chrome, signed in, at cursor.com/dashboard/shared-canvases) shows only the top of the canvas. The mouse wheel, trackpad, scrollbar, and Page Down do nothing. The same canvas scrolls normally when opened inside the Cursor editor.

The page itself has no scrollable overflow: document scrollHeight equals the viewport height. This is the cursor.com shared-canvas viewer, which is why the product is “Somewhere else” rather than the IDE.

Steps to Reproduce

  1. Create a canvas whose content is taller than the browser window.
  2. Publish it and open the share link in Chrome while signed in: https://cursor.com/dashboard/shared-canvases?shareId=…
  3. Try to scroll with the mouse wheel, trackpad, or Page Down.

Result: the view stays on the first screen. There is no scrollbar, and the wheel does nothing.

Expected Behavior

The canvas content scrolls, or the page grows to the height the iframe already reports via cursor-shared-canvas-resize. A reader should be able to reach the bottom of a shared canvas in the browser the same way they can in the editor.

Operating System

MacOS

Version Information

Cursor IDE 3.22.12 (Electron 42.10.0, Chromium 148.0.7778.280). The canvas scrolls correctly inside the editor. The failure is on cursor.com in Chrome, checked 30 Sep 2026. macOS.

Additional Information

I checked the forum first. Nothing matches this. Nearby reports are different: a standalone IDE canvas window going unresponsive (topic 166875), published canvas links needing a modified click (169468), /api/canvas-frame returning 404 (169974), and the IDE canvas max-width change (159574).

What the live viewer does:

The canvas is a sandboxed iframe at /api/canvas-frame/?theme=dark. The sandbox is “allow-scripts allow-popups allow-popups-to-escape-sandbox” (no allow-same-origin).

The shell is:

  • [data-shared-canvas-overlay]: position fixed, inset-x-0, top-0, z-index 100, flex column, overflow hidden, height 100dvh
  • [data-shared-canvas-body]: relative, min-height 0, flex-1, overflow hidden
  • iframe[data-shared-canvas-frame]: width 100%, height 100%

On a short window the iframe box was about 297px tall, and the parent document’s scrollHeight equaled its clientHeight, so a wheel on the page has nothing to move.

The iframe posts a cursor-shared-canvas-resize message with a height. The viewer writes that only to the CSS variable --shared-canvas-print-height, and the stylesheet applies it only inside @media print:

[data-shared-canvas-frame] { height: var(–shared-canvas-print-height, 100vh) !important; }

On screen the iframe stays height 100%. Forcing the iframe to 5000px made the resize message report 5048 (the iframe height plus the host’s 48px of body padding) and the rest of the canvas was visible below the fold. The content is intact. The viewer never gives it a scrollable box.

This showed up after the 3.22 canvas host update (3.21.18, then 3.22.7 on 22 Sep, then 3.22.12 on 26 Sep). A shared canvas first failed to scroll in Chrome on 28 Sep. The editor webview still scrolls.

A second issue on the same page: an open modal set pointer-events: none on body, while the canvas overlay sits above it at z-index 100, so wheel events pass through the iframe onto the backdrop. Closing that modal does not fix the clipping. The shell is still overflow hidden and the iframe is still height 100%.

Suggested fix: on screen, size the iframe from cursor-shared-canvas-resize (the same height already used for print) and let the page scroll. Or give the iframe a viewport-sized box and let the canvas document inside it scroll.

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hi @zdfs Thanks for the post! I tried to reproduce this bug but I couldn’t reproduce it as you’ve experienced it. On cursor.com the page itself is meant to stay fixed; the canvas scrolls inside its own frame. We tried the same layout with a tall canvas and it scrolls there, so we think something on the page is blocking input to the canvas. The dialog you noticed is our main suspect.

Could you try this and tell us what happens?

  1. Close every other cursor.com tab.
  2. Open the share link in a new tab and do a hard reload (Cmd+Shift+R).
  3. Don’t open any menus or dialogs on the page.
  4. Move the mouse over the canvas and scroll with the wheel or trackpad.
  5. If that doesn’t scroll, click once inside the canvas and press Page Down.

Does it scroll at step 4 or step 5? a screenshot would be helpful too!

In the meantime, “Download as PDF” in the canvas header gives you the whole canvas, and it still scrolls normally in the editor.

8

Hi @kevinn, thanks. I followed the steps exactly: one cursor.com tab, share link in a new tab, Cmd+Shift+R, no menus or dialogs opened.

Step 4: does not scroll. Step 5: does not scroll. The header does not take clicks either, so Download as PDF, Open in full screen and Copy link all do nothing.

DevTools on the freshly loaded page shows why input is dead. A Radix dialog (div[role="dialog"]#radix-…) opens on its own as soon as the canvas finishes loading: Grok Bot Terms, with Not now (focused) and Accept and Continue. It sits at z-index: 50 with a full-viewport .fixed.inset-0.z-50.bg-black/50 backdrop. The shared-canvas shell is fixed inset-x-0 top-0 z-[100] with an opaque background, so the dialog is never visible. While it is open, body is pointer-events: none and overflow: hidden, and the shell inherits that. document.elementsFromPoint at the center of each header button returns the backdrop DIV, not the button. Wheel events over the canvas land on the same backdrop.

Clicking Not now (or pressing Enter, since it has focus) removes the dialog, body goes back to pointer-events: auto, and the PDF button becomes the hit target. A reload brings the dialog back. This is an org-level terms prompt, so an account that has already accepted it will not see the problem, which would explain why your tall canvas scrolled.

So this thread has two things:

  1. The hidden dialog above, which blocks all input on the page for anyone who has not accepted the prompt. The canvas shell should not paint over a modal, or the modal should not open on the shared-canvas route.
  2. The sizing question from my first post (iframe fixed at viewport height, page has no overflow). I will confirm whether the frame scrolls once the dialog is dismissed and report back.

Share link (signed-in view): https://cursor.com/dashboard/shared-canvases?shareId=canvas-hQNdNxqSCKkXX02rRCuJr1MX

9

I ended up using DevTools to increase the zIndex and accepted the terms and now things work normally.

11

Cool, thank you for circling back and letting us know!

12

I’m sharing this with team so we can prevent this from happening in the future. Appreciate your detailed findings and sharing everything with us.