[Blocked] Starter page templates: Remove iframe from preview

[andrewserong]

A number of reported issues with the preview in the page layout picker can be resolved by removing the iframe from the preview. Certain blocks (such as masonry, or maps blocks) require JavaScript to complete their layouts in the case of masonry, or to perform API calls in the case of a map block. By removing the iframe, the preview has access to the JavaScript already loaded on the page, so we don't need to add any additional hacks to get these blocks working, and it also inches the preview a bit closer to how the preview works in the pattern inserter.

Issues resolved by this change:

• Fixes: Add New Page Screen: Contact Form not rendering correctly in preview #48889 (Contact form not rendered correctly)
• Fixes: Add new page screen: Issue with rendering map block in in preview #48883 (Issue with rendering map block in preview)
• Fixes part of: Add New Page Screen: rendering issue with galleries in thumbnails and previews #48881 (Rendering issue with galleries in thumbnails and previews)

Changes proposed in this Pull Request

• Remove the iframe from the starter page templates preview, and associated iframe methods
• Tweak styling and existing features to ensure there aren't any regressions

Screenshots

Note in the following that the map works in the preview, and that the masonry layout renders:

Testing instructions

• Sandbox the diff associated with this PR and a test site
• In your test site go to add a new page, and test that:
  • The masonry layout (the first Gallery layout) renders correctly in the preview (see Add New Page Screen: rendering issue with galleries in thumbnails and previews #48881 for more details) and note that this does not resolve the thumbnail on the button
  • The map renders in the preview for the second last Contact layout (see Add new page screen: Issue with rendering map block in in preview #48883 for more details
  • Test that switching layouts updates the post title in the preview
  • Test that resizing the window also re-scales the preview after a short while (300ms — the debounce timeout)
• Test that, in general, the preview looks better with this change applied than without it — there might still be some oddities, but the objective here is to ensure that it's an improvement
• Test across multiple browsers / devices to check for regressions

CC: @Automattic/ganon — just copying you in, in case you get a chance to review since you're also doing work on this area 🙂

[matticbot]

Test live: https://calypso.live/?branch=fix/page-layout-picker-issues-by-removing-iframe-from-preview

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[matticbot]

Caution: This PR affects files in the Editing Toolkit Plugin on WordPress.com
Please ensure your changes work on WordPress.com before merging.

D55737-code has been created so you can easily test it on your sandbox. See this FieldGuide page about developing the Editing Toolkit Plugin for more info: PCYsg-ly5-p2

[glendaviesnz]

This tests well for me ... just get the following error when I resize window with masonry gallery in preview, but error not there in iframe version:

[andrewserong]

Thanks for testing @glendaviesnz! I'll take a closer look.

[andrewserong]

just get the following error when I resize window with masonry gallery in preview, but error not there in iframe version:

It turns out this issue is caused by the Map block continuing to fire the resize event after the component has been unmounted. To reliably see the TypeError in the console, first select a pattern that includes the Map block (e.g. the second last layout under the Contact category), then select another pattern, and then resize the window. I believe we weren't seeing this in the iframe version because the JS was never running in the iframe context. I've put together a one-line fix in Automattic/jetpack#18489, but I think it should be fairly harmless to ignore the error in the meantime since it doesn't appear to block anything.

[andrewserong]

Okay, I've fixed the following:

• Scroll to top when switching layouts now works as expected
• Hide post title placeholder when empty so that we don't see Add Title from time to time in the preview
• Map block resizing error in the console (Map block: Remove resize event listener when component is unmounted jetpack#18489)

This is ready for any test/review. I've tested in Chrome, Firefox, and Edge on Mac, however I'm still having issues getting Safari to pick up most hosts file so if anyone gets a chance to test that out, that'd be a huge help! I'll try upgrading to Big Sur and see if that resolves anything with my dev environment.

[simison]

Adding the iframe fixed a whole lot of other fundamental issues originally (@retrofox worked on it and might have some links?), so I don't think this is feasible solution.

Furthermore, Ganon team is starting a project for redesigned page layout picker (pbAok1-1QJ-p2), so putting too much effort in this now isn't good, unless there are high priority bugs to be fixed? (I didn't look at the list yet)

[retrofox]

Adding the iframe fixed a whole lot of other fundamental issues originally (@retrofox worked on it and might have some links?), so I don't think this is feasible solution.

The bigger challenge for us was how to deal with the CSS media query. Have you tested the preview in small sizes?
Rendering into an iframe fixes this problem very well.

I agree that some themes require JS and it's an issue, though. That was something that was on our radar too.
I was working on passing the JS code to the iframe too in order to make it work, but I couldn't finish on time :-( Provably there is still an open PR for this :-)

[simison]

Ah yes, media-queries of course... I believe there were also CSS leakage and specificity issues cropping up frequently, but it's been a while so might remember wrong.

The site-editor itself is now in an iframe, and hopefully soon post-content too (WordPress/gutenberg#21102). Gutenberg is slowly making its way into Calypso as well, and doing so needs to solve some of those asset loading problems similar to here. So I'd expect if we need/want to do this in future, it'll become almost "for free".

But for now we've designed to live without the big preview, going forward.

[andrewserong]

Thanks for the feedback @simison and @retrofox!

The existing issues that this PR is designed to resolve are #48889 (Contact form not rendered correctly), #48883 (Issue with rendering map block in preview) and #48881 (Coblocks Masonry gallery does not render at all). The latter two visual issues are pretty bad, but I wouldn't consider this PR fix high priority, because in the short-term we could always unpublish the problematic layouts.

I think a fair bit has changed with how editor styles works since the initial iframe implementation, and in this PR the approach is pretty similar to the existing block previews in the pattern inserter, so at least in manual testing, it's been working quite well, and the existing rescale function seems to workaround the issues of media queries. I made a start at trying to transfer the JS over to the iframe to be loaded, too, but that quickly started looking like spaghetti so I abandoned the approach for this iframe removal instead.

All that said, given Ganon's work to redesign the layout picker (as you mention with pbAok1-1QJ-p2), I very much agree that it'd be better to avoid a potentially risky refactor if we're going to be throwing out the work in the short-term, anyway.

I'm happy to park this PR in lieu of the work to do the layout picker redesign, but it's always here in case the redesign is delayed and we need to add back in layouts that mightn't play nicely with the existing large preview 🙂

I'll update #48883 and #48881 with the suggestion that we unpublish the two or three layouts that are causing issues with the preview, until the redesign.

[sirreal]

I'll share some relevant context in case it's helpful:

• The timeline isn't well defined, but CoBlocks should be removed from these templates in the next few months. p7DVsv-9VL-p2
• The editor will likely move to be rendered in an iframe. This has already happened for the site editor. I'd expect it to happen for the post editor as well.
• Given the above direction, there's benefit in anticipating the changes and generally making blocks more resilient to rendering well in an iframe.
• This is slightly different as it's essentially a frontend and not an editor.

[andrewserong]

Update: I've explored a couple of different alternatives to this PR, but I believe this one is still the best candidate for resolving the reported issues (#48881, #48883, #48889).

With the way that the iframe is currently implemented, I haven't managed to get the Map block to work at all within the iframe because the block expects direct access to the DOM, and a ref through a React portal doesn't appear to work. As an alternative, in #49511 I tried out using the template/demo endpoint for the large preview instead, however that involves more drawbacks than the existing iframe, so doesn't appear to be a viable solution. I also attempted to use Gutenberg's Iframe component from the block-editor package as another alternative, but couldn't manage to get it working.

Returning this PR, it's still working pretty well for me, and I think is the best of the options I've explored. I haven't encountered any CSS bleed issues that I'm aware of, and the scaling of the preview appears to look okay. It doesn't hit the mobile breakpoints, so it means the effective preview size is as though you're previewing how the layout will look on desktop.

At this stage, having sunk a bit of time into a few different options, I think our best bet if we'd like to fix the linked issues before the new page layout picker is built, is to test and review this PR and merge it as an interim measure. If the PR isn't suitable, then let's put the linked issues into the backlog until the new page layout picker is built.

@simison what do you think? Is it worth us testing this PR out / getting it reviewed and getting these issues fixed in the short-term, or would you prefer to hold off?

[ramonjd]

At this stage, having sunk a bit of time into a few different options, I think our best bet if we'd like to fix the linked issues before the new page layout picker is built, is to test and review this PR and merge it as an interim measure.

We've started work on the new page picker today. Can't be sure of the "when", but I'd say that if this fixes things for the next month or two until we remove the iframe completely in the redesign, then I think it's safe (if everyone else does).

[simison]

@andrewserong meanwhile, do those blocks work in previews rendered from the API in screenshots?

[andrewserong]

@simison it looks like the blocks work correctly in the template/demo endpoint itself, but via mShots a few of them don't appear to render correctly. I suspect that mShots either a) mightn't be taking the screenshot late enough (once the JavaScript has done its thing), or b) mShots might not be executing the JavaScript at all? Either way, that'll need to be looked at separately. Is that something Ganon has scope to look into for the new page layout picker? If not, I can write up an issue for our backlog.

Let us know which way you'd like to go with this PR, happy to proceed to reviewing / getting it in, or park it until the new page layout picker is ready 🙂

[simison]

@andrewserong yah, would be good to have an issue for it at least.

There's prolly something that can be adjusted here:

https://github.com/Automattic/mShots/blob/748a64f945265cce1786393e43c4e9b43236d2b9/lib/snapshot.js#L174
https://pptr.dev/#?product=Puppeteer&version=main&show=api-pagewaitfornavigationoptions

[andrewserong]

Thanks @simison, I've written up the two issues I've encountered:

• mShots does not wait for JavaScript to complete before taking a screenshot (mShots does not appear to render Mapbox embeds mShots#30)
• template/demo endpoint: contact form blocks do not render correctly in isolated patterns (216-gh-Automattic/view-design)

I've added the latter to the View backlog. Would @Automattic/ganon have scope to look into the linked mShots issue as part of the page layout picker work? CC: @ramonjd

I think with these outstanding issues, and that they'd affect the screenshots on the left hand side in the existing modal, that's enough to tip me over into thinking we should park this PR and resolve the above as part of the new page layout picker work. I'm happy to have a go at the template/demo endpoint work.

Let me know if there are any objections, otherwise tomorrow I will close this and the alternative PR #49511, and update the linked issues that they're blocked by Automattic/mShots#30 and 216-gh-Automattic/view-design and will be resolved in the new page layout picker work.

[ramonjd]

Would @Automattic/ganon have scope to look into the linked mShots issue as part of the page layout picker work? CC: @ramonjd

Are there any other examples of pages not rendering correctly in mshots?

Or are we sure it's a Javascript execution/load time problem? See comment here

Maybe @deBhal has the time to dive into it. If we can't resolve it quickly, or it's limited to mapbox/canvas, perhaps we can think of alternatives, e.g., take a screenshots of a copy of that page, which contains a placeholder image or something?

[andrewserong]

Thanks for looking into it @ramonjd.

Are there any other examples of pages not rendering correctly in mshots? Or are we sure it's a Javascript execution/load time problem?

No, it's definitely more of a hunch than anything I'm sure of! Actually, now that I test it further, I think it might be that one particular block that isn't working correctly in mShots, so the mShots issue might be lower priority, then. I think the remaining issues might then be getting things to work properly in the template/demo endpoint. I'll write up further issues as I encounter them.

Update: the two main template/demo endpoint issues I've encountered so far are: 216-gh-Automattic/view-design and 219-gh-Automattic/view-design

[andrewserong]

@simison while testing other block rendering issues, I encountered a more pressing issue with the existing iframe (Google fonts don't appear to be loading — #49742). I've double-checked and confirmed that this PR would resolve that issue, so I've given this PR another rebase to make sure it's still working correctly. So, there could still be a good case to be made for getting this PR in. What do you think?

[andrewserong]

Since there is a different refactor of the starter page templates going on in #49661, I'll close this PR. @Automattic/ganon just a heads-up, if you wind up running into any issues with the large preview in your refactoring / rebuilding work for the page layout picker, feel free to borrow from this PR if it helps 🙂