Zoomed-out images can't be zoomed back in.

[raven92]

In my blog posts I let users zoom out (amplify) the images so they can see the details, however, once they zoom out the images they can't be zoomed back in, the X button does not respond at all.

This used to work just fine, but after a wordpress version upgrade this stated happening.

[raven92]

Once an image gets zoomed out, it can't be zoomed back in, the X button does not work.

[hbhalodia]

Hi @raven92, Thanks for the issue.

I tried to reproduce the issue at my end, but I am unable to reproduce it.

Could help me with exact WP version you are using and also make sure to test by deactivating all the plugins and default WP theme. Or if you can share an screencast on how you are reproducing the issue would be helpful to debug and resolve.

[raven92]

Replying to hbhalodia:Hello @hbhalodia , thank you for your response. If you go to my website, any blog post can be used to experice the issue in real time, check this blog post for example :

​https://integracontrols.com/ddc-controls-in-hvac/

if you click on any image on the post it will let you amplify it, once that's done you can't close it back.

Please try and let me know.

My wordpress version is 7.1.2.

Thank you in advance for the help.

[hbhalodia]

Hi @raven92, Thanks. It looks like the issue is with your site not closing the div tag correctly. See the below response,

Short version
This isn't a WordPress core bug. The HTML your site sends opens a wrapper, <div id="page" class="hfeed site">, and never closes it. Older WordPress versions didn't care about that.

What happens when you open an image
When you click an image, WordPress shows it in a fullscreen popup (the lightbox). To make the popup behave like a proper modal, WordPress 7.0 temporarily "freezes" the rest of the page so it can't be clicked or tabbed into while the popup is open. This is a standard accessibility pattern that uses the browser's inert attribute.

To do this, WordPress freezes everything on the page except the popup. It expects the popup to sit on its own at the top level of the page, next to the site content and not inside it.

What's different on your site
Your header is built with Header Footer Elementor and your footer with Elementor Pro. The header opens the #page wrapper, but because the footer comes from a different plugin, nothing closes it. Everything WordPress adds at the bottom of the page, including the lightbox popup, ends up inside that wrapper. This is just the assumption that it might be the cause, but you need to check why and from where the wrapper can be closed.

So when you open an image:

1. WordPress freezes the #page wrapper, as intended.
2. The popup is inside that wrapper, so it gets frozen too.
3. The close button, the next/previous arrows, clicking the background and the Esc key all stop responding.

"If you see a closing </div> for #page"
If you're looking in your browser's Developer Tools (Inspect → Elements). That panel doesn't show the HTML your site sends. It shows the page after the browser has already repaired it.

When a browser finds a <div> that was never closed, it closes it automatically at the end of the page, and Developer Tools then shows a </div> that isn't in your site's HTML.

The raw HTML is what matters, and there you can see the wrapper isn't closed:

• Open View Page Source (Ctrl+U on Windows or Cmd+Option+U on Mac), not Developer Tools.
• Search for </footer>.
• Right after the footer there's no </div>. The page goes straight into WordPress's footer scripts and the lightbox popup, then ends with </body>.

Why it started after the update
The unclosed wrapper was already there before the update. Until WordPress 6.9 the lightbox never froze the rest of the page, so the broken wrapper did no harm. WordPress newer version added the freezing behavior together with the new gallery next/previous arrows, and that's when the problem appeared.

Recommended fix
I recommend fixing the page structure.

1. Preferred: build the header and footer with the same tool (both Elementor Pro Theme Builder, or both Header Footer Elementor), so the wrapper opens and closes as intended.
2. Alternative: add a small code snippet that closes the wrapper at the right point in the page.

Thanks,

[hbhalodia]

Hi @raven92, I have also opened an issue upstream to GB repository - ​https://github.com/WordPress/gutenberg/issues/83479

The issue can happened if the opened div in your case is closed after the footer, so that is not handled correctly in the Gutenberg. So ideally the fix should also be land in the upstream as well.

[hbhalodia]

Update - Added the PR to fix the issue over Gutenberg.

PR - ​https://github.com/WordPress/gutenberg/pull/83480

[raven92]

Hello @hbhalodia, Thank you for the response and for scalating this issue.

The site UX has been hit hard due to this issue.

Do you think this bug will be resolved anytime soon or do I go ahead and find a way o fix this on my own ?

Let me know,

[hbhalodia]

Hi @raven92, Thanks. The best I could say now is to update your site structure so that the image overlay is the direct child of the body as mentioned. Which would fix that in your case unitl the bug is fixed in core.

[hbhalodia]

Hi @raven92, The upstream PR has been merged to Gutenberg. The next WP release would fix the issue.

PR - ​https://github.com/WordPress/gutenberg/pull/83480