Scroll to selected block when switching viewport preview

[sunmorgn]

What problem does this address?

When using the viewport preview feature (Mobile/Tablet/Desktop buttons in the editor toolbar), the editor canvas resizes but does not maintain scroll position relative to the currently selected block.

I'm always frustrated when switching between viewport sizes because I lose my place in the document. On longer pages, I have to manually scroll to find the block I was working on after each viewport switch. This significantly slows down the responsive design workflow.

Steps to reproduce:

1. Create a page with multiple blocks (enough to require scrolling)
2. Select a block that's not at the top of the page
3. Click the viewport preview button (e.g., switch from Desktop to Mobile)
4. Observe that the selected block is no longer visible in the viewport

What is your proposed solution?

Automatically scroll to the currently selected block after switching viewport preview modes.

The implementation would:

1. Subscribe to device type changes in the editor store
2. Track the currently selected block
3. After the viewport transition animation completes (~500ms), scroll the selected block into view (centered)

I have an elegent working solution and am happy to submit a PR if this approach is acceptable - would love to see this improvement in 7.0

[Mamaduka]

A similar behavior was recently implemented when switching between entities in the editors (#73737). I think it could be a nice UX improvement if done correctly.

cc @mtias, @tellthemachines, @youknowriad

[t-hamano]

As far as I've tested, the scroll position is generally preserved:

fbc3bf3aec247c6c09c11a479f8cce6d.mp4

Perhaps this is because the editor is not iframed in the desktop preview? In the desktop preview, if a block of version v2 or lower is registered, it will not work as an iframe editor. On the other hand, in the tablet and mobile previews, the editor always works as an iframe. The scroll position may be reset because the editor instances are different.
see
In the future, it is planned that the desktop preview will also always work as an iframe editor. See https://github.com/WordPress/gutenberg/blob/trunk/docs/reference-guides/block-api/block-api-versions/block-migration-for-iframe-editor-compatibility.md

[mtias]

Was there any further testing on this? Agreed we should handle this as best as we can.

[Mamaduka]

The plan is to start using iframed editors everywhere, including device previews, which could resolve this issue as a side effect. The most recent efforts are here: #75187 and #74042.