Popup Inside close button does not close modal

[pirate-bot]

Summary

The Popup block can show a visible close icon when Show Close Button is enabled, but the default Inside position appears not to close the popup when clicked.

Expected behavior: clicking the visible close icon closes the popup for both Inside and Outside positions.

Actual behavior: the Inside close icon is visible but clicking it does not close the popup in the reported workflow; changing the close button position to Outside makes the same close action work.

Impact: visitors may be unable to dismiss a popup using the visible close icon when the default inside position is used.

Customer context

• Product / area: Otter Blocks Popup block
• Version: Not provided in the thread; current inspected repository state is tagged v3.1.11
• Environment: WordPress.org support forum report; popup added to the home page
• Integration / third party: Not provided
• Reported error / symptom: Visible X close button does not dismiss the popup when Close Button Position is Inside; Outside works
• Impact: Popup may remain open when users click the visible inside close icon

Reproduction notes

Reported steps:

1. Add a Popup block to the home page.
2. In Popup settings, enable Show Close Button.
3. Leave Close Button Position at the default Inside setting.
4. View the popup and click the visible X close icon.
5. Observed: the popup does not close.
6. Change Close Button Position to Outside.
7. Observed: clicking the close icon works.

Reproduction status: not run locally during triage. Source inspection supports the reported Inside/Outside difference. Missing details: installed plugin version, WordPress version, theme, browser, and popup content/layout.

Diagnosis

Conclusion

The report is confirmed as a product-side defect in the Popup block frontend path. The transcript reports that the visible close icon fails only for the default Inside position while the same UI works after switching to Outside. Code inspection supports a CSS/hit-testing failure: the same close-button markup and JavaScript handler are used for both positions, but the Outside variant receives additional positioning and stacking styles that the default Inside variant does not.

Inference: the Inside close icon is likely visible but not receiving the click event in the reported layout, while the Outside variant receives clicks because its style path places the button above the modal content.

Where this likely occurs

• User-visible surface: Otter Blocks Popup block, Close Button settings panel, Position set to Inside.
• src/blocks/blocks/popup/inspector.js — Inspector() lines 365–383: Show Close Button toggles showClose; Inside is represented by undefined via the none option, while Outside stores closeButtonType: 'outside'.
• src/blocks/blocks/popup/save.js — Save() lines 16–24 and 38–42: the wrapper only gets with-outside-button when closeButtonType === 'outside'; both positions render the same .otter-popup__modal_header > button.components-button.has-icon close button markup.
• src/blocks/frontend/popup/popup.ts — PopupBlock.bindCloseButtons() lines 234–241: frontend JavaScript binds clicks on .otter-popup__modal_header .components-button and calls closeModal(). There is no separate Inside/Outside branch in the close handler.
• src/blocks/blocks/popup/style.scss — popup styles lines 121–138: the default inside header is absolutely positioned with right: var( --padding ); the nested button has z-index: 2 without its own positioning in this style branch.
• src/blocks/blocks/popup/style.scss — popup styles lines 156–174: the with-outside-button branch changes the header positioning and gives the button position: absolute plus z-index: 9, matching the reporter’s observation that Outside works.
• Git history: git blame and git show identify d4c1f328a (fix: Popup structure to better support padding) as the change that replaced the previous inside header flex layout with absolute positioning and adjusted the outside header. git tag --contains d4c1f328a shows the change is present from v3.1.0 through current v3.1.11.

Engineering notes

The failure surface appears isolated to the frontend Popup close button’s default inside styling path. The close handler itself appears shared and reachable for both variants, and the saved markup for the button is identical across positions except for the wrapper class that enables the outside-specific CSS branch.

The thread’s comparison between Inside and Outside narrows the defect away from missing frontend script enqueueing, missing button markup, or a generally broken closeModal() path. The likely failing contract is that a visible close button is expected to be clickable in the default inside position, but the inspected CSS creates different stacking/positioning behavior between the two variants.

The Pro modal/editor files were lightly checked because the monorepo contains Pro block sources, but the reported WordPress.org product and code evidence point to the free Popup block frontend path in src/blocks/blocks/popup/ and src/blocks/frontend/popup/.

Test coverage status

Relevant e2e tests exist but do not cover clicking the visible close button. src/blocks/test/e2e/blocks/popup.spec.js — test.describe( 'Popup' ) lines 11–48 covers opening a popup via anchor, and lines 50–72 covers closing by Escape. src/blocks/test/e2e/blocks/modal.spec.js — test.describe( 'Modal' ) lines 11–47 and 49–87 has similar open/Escape coverage for Modal. No relevant coverage for showClose, closeButtonType, with-outside-button, or close-button click behavior was found during inspection.

What to verify or explore next

• May be worth reproducing with Playwright by creating a Popup block using default showClose and default Inside position, opening it on the frontend, and clicking .otter-popup__modal_header .components-button.
• May be worth comparing the same test with closeButtonType: 'outside' to confirm the reported position-dependent behavior in the test environment.
• May be worth checking built release assets around v3.1.0 and current v3.1.11 to confirm the source-level regression boundary matches packaged CSS.
• May be worth verifying whether custom popup padding, content height, mobile width, or theme CSS changes affect clickability of the inside close icon.

Unknowns / follow-up

• The thread does not provide the installed Otter version, WordPress version, active theme, browser, or custom popup content.
• Local browser reproduction was not run during this triage; confirmation is based on the user’s clear report plus source and git-history evidence.
• The exact element receiving the failed click in the customer’s browser was not captured.

Confidence

Confidence: 84/100

The HelpScout report gives a clear position-dependent failure, and repository inspection shows the Inside and Outside close buttons share the same frontend handler while only the Outside variant gets effective positioning/stacking styles. This makes a product-side popup close-button defect likely enough to open an issue.

---

Source: HelpScout #3356055307
Generated by bug-report-triage workflow (ID: bug-report-triage_6a3021a02e9b22.67065207)

[pirate-bot]

Another customer requested this via support.

Context: The customer built a popup with a multi-column layout for an image. They found that the column's padding visually overlaps the default 'Inside' close button, preventing it from being clicked. They diagnosed the issue themselves, noting the missing z-index on the wrapper div, and are currently using the 'Outside' button position as a functioning workaround.

Source: HelpScout #3358484571

---

Generated by feature-request-triage workflow (ID: feature-request-triage_6a329a6fc1b109.78553534)

[pirate-bot]

Another customer requested this via support.

Context: The customer added a popup to their homepage. They noticed the close button ('X') doesn't do anything. They discovered it works if the position is 'Outside', but fails on the default 'Inside' setting. The customer identified that the 2nd column's padding overlays the close button, making it unclickable without an explicit z-index applied to the otter-popup__modal_header wrapper.

Source: HelpScout #3358446120

---

Generated by feature-request-triage workflow (ID: feature-request-triage_6a329a6fc62bd7.73128467)

[pirate-bot]

🎉 This issue has been resolved in version 3.2.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀