fix(CardHorizontla): 🐛 button event bubbling (double onClick)

[punkbit]

Why?

To fix CardHorizontal double onClick handler bug, where clicking the inner Button would invoke onButtonClick and window.open(infoUrl) twice due to event bubbling. Fixed by adding event stop propagation method to the button's click handler.

How?

• Created a handler
• Add e.stopPropagation()
• Call original

Tickets?

N/A

Contribution checklist?

• You've done enough research before writing
• You have reviewed the PR
• The commit messages are detailed
• The build command runs locally
• Assets or static content are linked and stored in the project
• For documentation, guides or references, you've tested the commands

Preview?

N/A

[changeset-bot]

🦋 Changeset detected

Latest commit: a1df536

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@clickhouse/click-ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[workflow-authentication-public]

📚 Storybook Preview Deployed

✅ Preview URL: https://click-iru2kt44d-clickhouse.vercel.app

Built from commit: 8c37fd4cfb43bcfdd1758b6c38c1875fa305ebae

[punkbit]

• CardHorizontal.tsx:209 — pre-existing, out of scope for this PR: infoUrl is passed to window.open() without URL validation. Per the repo's .llm/SECURITY.md, external URLs should be validated before use. Worth a follow-up issue to guard against javascript: URLs — e.g., if (infoUrl.startsWith('http')) or a URL constructor check.

This has already been addressed in a separate PR, which is pending approval. Do ignore!

[punkbit]

• CardHorizontal.tsx:199 — naming clarity: handleClick is used both as the Wrapper's onClick handler and as the shared logic called from handleButtonClick. A name like handleCardAction would make it clearer that it's the shared action function rather than specifically the card's click handler — the current name implies it's only the wrapper's handler, which makes handleButtonClick calling it directly feel slightly surprising when reading.

Took a note and will be looked at in future refactoring. Do ignore!

[github-actions]

Claude finished @punkbit's task in 1m 3s —— View job

---

PR Review

• Read CLAUDE.md and .llm conventions files
• Read changed files
• Provide review feedback

---

Solid fix, well-tested, and cleanly scoped. Here's the full review:

🟢 Fix is correct

The two-handler pattern is sound:

• handleClick (line 199) — Wrapper's onClick, guards for disabled, calls onButtonClick, opens infoUrl
• handleButtonClick (line 216) — Button's onClick, stops propagation, then directly calls handleClick

useCallback dependencies are correct on both handlers. No logic duplication.

🧪 Tests are solid

The two new regression tests (lines 192–217) use userEvent.click for realistic event simulation and verify both onButtonClick and window.open are each called exactly once. They use renderCUI() per repo conventions. ✓

📦 Changeset

Patch-level changeset is appropriate — concise description is fine for a bug fix per .llm/CONVENTIONS.md. ✓

💡 Pre-existing issues (out of scope, already acknowledged)

• {...props} spread after onClick={handleClick} (line 233) means a consumer-passed onClick silently overrides the internal handler — punkbit confirmed a separate PR is addressing this.
• handleClick naming — noted and deferred to future refactor.

---

✅ Ready to merge. The bug is fixed, tests cover the regression, and the changeset is in place.

[punkbit]

• {...props} spread after onClick={handleClick} (line 233) means a consumer-passed onClick silently overrides the internal handler — punkbit confirmed a separate PR is addressing this.

Noted and will be taken care of in next iterations. Do ignore!