Preview is empty if launched manually after some input provided

So the fix doesn't work if I do this:

1. Add new content
2. In the iframe settings, disable Open preview by default
3. Close and reload the page
4. Type anything in the title and click the preview button

The page is empty.

Okay, so this is weird. After the first time, it works correctly. Narrowed it down to being connected to the twig cache in some way, every time I flush it, the problem shows up.

Thanks for the error report @admirlju I'll try to reproduce and analyze.

So I've been digging a bit more. I'm not yet sure, but a few things I noticed, might help debug further.

So I'm looking at the module file, and how the iframe and preview compiling is added in same_page_preview_form_node_form_alter.
Noticed one thing, when the preview button is clicked but the pane is not open, this hook is called twice, the first time when it opens the pane, the UUID of the preview is wrong, and the second call uses the correct UUID and then displays the data. Now the weird part here, the UUID in $route_parameters in the first run does not match the UUID loaded in the pane, the second time it does match, so this first run never shows the correct preview node.

So knowing this I went to check the PreviewPaneController.php, so the controller for the pane. An interesting thing happens here if I put a breakpoint, at any point, in the view method. It delays how long the pane needs to open, and this causes this second hook run to not update the preview.

So what I'm assuming happens, after clearing the twig cache, the time to build the preview page is longer and this second call happens before the pane preview page is displayed. However, when the node cache is built, the pane display is fast enough for the second call to refresh the page.

Also, elements that update the preview on blur, open a preview pane that is empty and use the wrong UUID. So this is a bigger problem in general.

I created a patch to solve this problem

I think..... Maybe we've already applied the fix that is in #11. Well, most of it. We aren't (in code) defaulting the display to the 'full' display mode. But doing so might be dangerous because it is possible to get rid of the 'full' display mode. So hard coding that feels dangerous.

Can you retest? Is this still an issue?