Post Preview modal no longer loading

[mrfoxtalbot]

We have noticed that Calypso's modal is no longer loading. Instead, users are taking to a preview in the "front end" (as if they were using the WP-Admin editor instead), for instance:
https://example.wordpress.com/?p=1234&preview=true

Screen.Recording.on.2021-06-25.at.11_23_25.mp4

Is this intended, or is it a regression?

[AlexanderMonsanto]

Possibly related ticket zd-4094204

[devNigel]

Here's another case

User report: 30098471-hc
Ticket: 4093594-zen

[AlexanderMonsanto]

Another ticket: 4094525-zen

[hngdny]

Possibly another one here: 4094244-zen

[kriskarkoski]

I believe #4097705-zen is related to this. I had an additional report as well before realizing this was the issue that I'll add if/when I find it. In my testing the modal loads but the preview also opens in a new tab on the first attempt.

In this case the user is seeing Page Not Found in the window that opens. Maybe a third-party cookie issue where they're not logged into the site that our change to logins to custom domains might help?

[kriskarkoski]

#4097787-zen

[kriskarkoski]

4098156-zen

[ktyfuller604]

Similar report here, they got a page not found when previewing a scheduled post. #2347495-hc

[kwight]

The "page not found" seems to be transitory (at least the time I saw it); "page not found" would flash, then the correct post would load.

[kwight]

I'm labelling this as "normal" because it's an obviously broken WP.com experience, but it has reverted to WP core behaviour of opening in a new tab (which works most of the time?). There are no recent ETK, wpcom-block-editor, or Calypso changes that would seem to account for it.

[the-misha]

4097219-zd-woothemes

EDIT: This seems to be an issue for posts in Draft, as I'm able to preview Published posts without an issue. Also, if I select Preview from the "three dots" menu from the Posts page, I can preview the post without issue.

[joweber123]

I have created three how-to-videos to show how a user can use the responsive design mode in Safari, Chrome, Firefox as a workaround while this is being fixed.

Safari How-to-Video - https://d.pr/i/44ySht
Safari Guide - https://developer.apple.com/safari/tools/

Chrome How-to-Video- https://d.pr/i/fPArfd
Chrome Guide - https://developer.chrome.com/docs/devtools/device-mode/

Firefox How-to-Video- https://d.pr/i/td6SVJ
https://developer.mozilla.org/en-US/docs/Tools/Responsive_Design_Mode

[rezzap]

Another report of this in 4099282-zen seeing the "page can't be found" report. I'll gather more details before providing how-to guides.

[jsnajdr]

This is what I found when debugging this:

Natively, the button.editor-post-preview click event is handled by the openPreviewButton method in Gutenberg. That method opens the preview in a new tab. When I'm testing in Calypso iframe, this method is called, although it shouldn't be (see below). And it crashes with an exception:

Blocked a frame with origin "https://jsnajdrtestsite3479.wordpress.com" from accessing a cross-origin frame.

That exception is thrown in the writeInterstitialMessage function which uses document.write to write a temporary message into the preview tab document. Apparently this cannot be done in a Calypso iframe.

Calypso iframe is supposed to override the native method by registering its own click handler for button.editor-post-preview here. That handler is supposed to run before the native one, open a Calypso preview, and prevent the native handler from running by calling stopPropagation().

But although the Calypso handler is registered, it never runs. I suspect it's because the order in which they are registered was reversed recently. Both are on the same element: the div#editor one. The Calypso handler attaches it to div#editor explicitly, and because div#editor is the React root where the editor is mounted, the button.editor-post-preview handler actually runs on this element.

Why is the order reversed? Because Gutenberg upgraded from React 16 to React 17 two weeks ago in WordPress/gutenberg#29118. And that major version changed where React attaches its event handlers. The native openPreviewButton handler that we want to override used to be registered on document, being safely preceded by the overriding handler on div#editor, but now they are on the same element and their order is reversed.

[KokkieH]

Another report in https://wordpress.com/forums/topic/previewing-post-layouts-in-mobile-tablet-desktop/

[AlexanderMonsanto]

possibly related zen-4094525

[pablinos]

I've just deployed #54127 that fixes this issue, so I'm closing it.

[KokkieH]

Can confirm it works for me now.

[jtobiesen]

Found a ticket that seems related. 5413341-zen

User is reports being redirected to a page not found when previewing a draft post.
Workaround- User can preview draft post from the the All Post screen in WP Admin

Customer using:


• Firefox browser 102.0.1
• 
Also in the private browser on Opera

[github-actions]

Support References

This comment is automatically generated. Please do not edit it.

• 4093594-zen
• 4094525-zen
• 4094244-zen
• 4097705-zen
• 4097787-zen
• 4098156-zen
• 4097219-zen
• 4099282-zen
• 5413341-zen

[carinapilar]

In reply to @jtobiesen's comment above, it seems that the issue from that user specifically is related to this other GH thread instead: #57812