WYSIWYG fields empty on load under Block Editor - TinyMCE holds a detached docum

Hi,

WYSIWYG fields in our meta boxes show no content when the post edit screen loads. Switching to the Text tab shows the content correctly; switching back to Visual leaves it empty again.

Environment:
- WordPress 7.1
- Block Editor active
- Custom post type with seven Meta Box WYSIWYG fields
- Chrome, reproducible in incognito
- Happens more often for Editor-role users than for Administrators, and it is intermittent - occasionally a page load works fine

Console error on load and when switching back to Visual:

Uncaught TypeError: Cannot read properties of null (reading 'setBaseAndExtent')
at i (wp-tinymce.js?ver=49110-20250317:3:291936)
at Object.each (wp-tinymce.js?ver=49110-20250317:3:1346)
at Object.select (wp-tinymce.js?ver=49110-20250317:3:293163)
at _ (editor.min.js?ver=7.1:2:5063)
at n (editor.min.js?ver=7.1:2:1731)
at HTMLDocument.<anonymous> (editor.min.js?ver=7.1:2:248)

We traced this further than the existing reports, and the root cause looks specific enough that I want to share it.

The frames map to wp-admin/js/editor.js: _ is focusHTMLBookmarkInVisualEditor(), n is the 'tinymce-editor-init.keep-scroll-position' handler. That handler calls editor.focus() and editor.selection.select(). The reason getSelection() returns null is that the editor's document is detached.

Run in the console on an affected edit screen:

tinymce.editors.map(e => {
var doc = e.getDoc(), ifr = e.iframeElement;
return {
id: e.id,
sameDoc: doc === (ifr && ifr.contentDocument),
hasDefaultView: !!doc.defaultView,
lenInEditor: e.getBody() ? e.getBody().innerHTML.length : null,
lenInIframe: ifr && ifr.contentDocument && ifr.contentDocument.body ? ifr.contentDocument.body.innerHTML.length : null
};
})

Result for all seven fields:

sameDoc: false
hasDefaultView: false
lenInEditor: 412 / 1516 / 625 / 30 ...
lenInIframe: 0

So the content is present in the TinyMCE instance, but the visible iframe is empty, and the instance's document is no longer the iframe's contentDocument. Our reading: the Block Editor relocates the classic meta boxes in the DOM after they are rendered. Moving an iframe in the DOM forces the browser to reload it and create a fresh contentDocument, while TinyMCE keeps a reference to the old one. A detached document has no defaultView, which is exactly why getSelection() returns null and the core error is thrown.

The wrapper classes, the iframe dimensions and the editor content are all correct at that point - only the document reference is stale. So this is not the same thing as the timing/load-order theory discussed in the existing reports:

https://core.trac.wordpress.org/ticket/62450
https://github.com/WordPress/gutenberg/issues/74627

Since Meta Box has its own re-render logic for TinyMCE under the Block Editor, could you check whether the editors can be re-initialised after Gutenberg has finished moving the meta boxes? Detecting the stale document is cheap (doc !== iframeElement.contentDocument), which would make the fix independent of load timing.

We are currently working around this by disabling the Block Editor for one post type via use_block_editor_for_post_type, but that is not an option for our other post types, which contain real block content.

Happy to provide site access or run further diagnostics if that helps.

Thanks,
Markus