"Preview mode": Page reloads after navigation

[purplespider]

When editing a page in the CMS, if you open "Preview mode" and then click a link to navigate to another page, the new page loads, but then immediately reloads a split second later.

On some sites this is more noticeable than others, and on sites with on-load transitions, it is especially annoying as it looks like the transition occurs twice.

It seems to be related to the presence of $MetaTags(false) in the template, as if you remove this line the reload issue doesn't occur.

This can be easily reproduced in a clean Silverstripe 4.11.0 install. To make the issue more obvious, you can add a transition to the body, e.g. add this to the head in templates/Page.ss.

<style>
	@keyframes slideInFromLeft { 0% { transform: translateX(-100%);} 100% {transform: translateX(0);}}
	body { animation: 0.5s ease-out 0s 1 slideInFromLeft;}
</style>

Here you can see the pages load twice:

If you remove $MetaTags(false) the issue goes away:

[GuySartorelli]

What's happening is that when you click on a new page, the CMS picks up that it's not the same as the page you were editing. So it actually navigates to the edit form for the page you're now previewing. You can see this in action if you use the split mode instead of the preview mode.

The way to avoid this is, as you've noted, to not use $MetaTags in your template.

It might be worth us having some UX advice on this though - when in preview mode it does indeed look like a bug since you can't see that the edit form has changed. Maybe we need a toast message when this happens...

[purplespider]

Ah, I had wondered if it was something like that, but forgot to try split view.

I'm not sure a toast will really help though, as depending on a specific site's page load experience this issue will be different for every site. e.g more notifiable on slow servers or sites with on-load animations or actions. I can see users not necessarily linking the toast with the observed behaviour (e.g. repeating page animation), and of course, it doesn't actually fix the odd behaviour.

Removing $MetaTags isn't always a viable option, as it is used by modules such as Opengraph/Share Care. Plus it's a shame to lose the feature of the edit form updating automatically when navigating the preview.

An ideal solution here is to just stop the CMS from re-loading the preview when it doesn't have to. The CMS must already detect the change in the x-page-id meta tag, so perhaps it could check if its value already matches the current edit form ID, so it can choose not to re-load the preview?

[GuySartorelli]

The preview panel is tied directly to the edit form template. With the way it's currently architectured, we can't change what form we're looking at without also loading a new preview panel.
It's something we could look at changing in a future major version perhaps, but there's probably some ux improvements we can do in the meantime to more clearly communicate what's going on.

[purplespider]

Ah ok, I wondered if that could be the case.

Would it be complicated to tell it to not update the edit form when navigating the preview (unless in Split mode), and the edit form update could instead be triggered when changing from Preview mode back to Edit mode (or when Draft/Published toggle is changed). It wouldn't fix the issue on Split mode but would eliminate unnecessary Edit form loads and as such also the unnecessary Preview loads.

[GuySartorelli]

That's definitely a clean option, and I don't think it would be too difficult. We'd just need a mechanism to store a pending edit form location when in preview mode, and check that when swapping modes.