Fixed: zoom out can hide the scrollbar

[dhruvang21]

What?

fixes the issue of scrollbar gets hidden when block inserter sidebar is open while zoomout view is enabled

Closes #65595

Why?

This PR fixes the issue of scrollbar gets hidden when block inserter sidebar is open while zoomout view is enabled

How?

When zoomout view is enabled we maintain the prevContainerWidthRef.current = containerWidth in the iframe.

Testing Instructions

• Zoom out
• Open a sidebar

Screenshots or screencast

issue-65595.webm

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: dhruvang21 <[email protected]>
Co-authored-by: draganescu <[email protected]>
Co-authored-by: getdave <[email protected]>
Co-authored-by: stokesman <[email protected]>
Co-authored-by: colorful-tones <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[draganescu]

Does this take into account the media querries issue detailed by @stokesman in the original issue?

[dhruvang21]

Does this take into account the media querries issue detailed by @stokesman in the original issue?

yes i think it does take in the account as the below screenshot is same as the issue which was reproduce but this time it does not have the mobile menu and also the scrollbar is visible.

[getdave]

When zoomout view is enabled we maintain the prevContainerWidthRef.current = containerWidth in the iframe.

Thanks for the PR 👍

Are you able to going in to some more detail on why what you describe above solves the issue? I'd like to understand the solution a bit better but as it's a one-line code change that's quite challenging. Many thanks.

[stokesman]

This works without introducing breakpoint inaccuracy however it sacrifices the ability of zoom out to display the full (initial) canvas width when zoom out is engaged prior to opening any sidebars. Here’s a comparison from a starting viewport width of 1080 pixels.

trunk	this branch

The fact that the full width view depends on zooming out before opening sidebars is a bit of a separate issue. It used to be that zoom out always showed the full width when it could only be engaged by selecting the patterns tab in the Inserter. The full width view seems like what is originally intended for zoom out so I don’t expect we want to lose it completely.

I did cover this in the issue I opened but it’s not easy to do succinctly and clearly so I understand if it wasn’t understood.

[dhruvang21]

Hi @getdave,

I’ve updated the condition for isZoomout so that the zoom-out preview container width matches the container width. Since the container width is dynamically calculated, I thought setting the zoom-out preview width the same would allow the scrollbar to automatically adjust within the window. This worked well and resolved this issue, as well as #65654.

However, after reading @stokesman comment, I now understand the issue with the media query more clearly. The zoom-out preview width shouldn’t change inside the iframe, but by altering the condition, it does, which triggers the mobile view.

Now, the question is whether this solution is valid or not. I still believe we need to adjust the condition to maintain the width so the scrollbar appears. I’d love to hear your thoughts on this, and if this approach isn’t correct, I’d appreciate any suggestions for an alternative solution.

Thanks!

[getdave]

I believe this problem will be solved by #66034. I think we should continue over there. What do you think @dhruvang21?

[dhruvang21]

I believe this problem will be solved by #66034. I think we should continue over there. What do you think @dhruvang21?

Yes, sure @getdave, we can proceed with the PR you mentioned above.

[colorful-tones]

Closes #65595

Based on the fact that #65595 is now closed and:

I believe this problem will be solved by #66034.

I think we can close this PR, correct? @dhruvang21