feat(docs): add "Create a support ticket" to the page feedback toolbar

[ketanyekale]

Description

Adds a third option — Create a support ticket — to the page feedback toolbar, next to Mintlify's built-in "Suggest edits" and "Raise issue". It links to the Help Center request form at help.cometchat.com/hc/en-us/requests/new.

Both built-in buttons are hard-wired to this GitHub repo. A reader who spots a typo is asked to fork the repository to propose a change, which means a GitHub account and a PR flow for a one-line fix. Readers without a GitHub account currently have no way to report a docs problem at all.

Why this is a script and not config: the feedback toolbar is not configurable. There is no feedback key anywhere in the live docs.json schema (no suggestEdit, raiseIssue, or thumbsRating), and the built-in toggles live in the Mintlify dashboard under Add-ons. There is no option to point "Suggest edits" at a custom URL. So the third option is injected client-side, following the existing assets/*.js pattern (consent.js, version-aligner.js) — Mintlify loads every .js file in the content directory on every page (custom scripts).

Implementation notes:

• Copies the sibling button's className, so styling and dark mode stay in sync automatically if Mintlify restyles the toolbar
• Re-injects on client-side navigation (the toolbar is re-rendered on every route change) and is idempotent
• Falls back to building its own row if "Suggest edits" and "Raise issue" are ever switched off in the dashboard

Related Issue(s)

Raised by Nisha in Slack: the "Suggest edits" flow requires a GitHub login and a repository fork, which is a lot of friction for a quick documentation improvement.

Type of Change

• Improvement to existing documentation

Checklist

• I have read the CONTRIBUTING document
• My branch name follows the naming convention
• My changes follow the documentation style guide
• I have checked for spelling and grammar errors
• All links in my changes are valid and working
• My changes are accurately described in this pull request

Additional Information

Verified by running the same code against the live docs site:

• Renders third in the row: ["Suggest edits", "Raise issue", "Create a support ticket"]
• Computed padding, border radius, border, colour and font size are identical to the sibling buttons
• Icon renders at 14x14, matching the others
• After a client-side navigation to another page: still injected, exactly one copy, no duplicates

Two open questions for reviewers:

1. No page context reaches the ticket. The Help Center form is a custom theme whose inputs carry ids but no name attributes, so Zendesk's ?tf_subject= / ?tf_description= prefill has no effect. Support will receive a docs ticket with no indication of which page it is about, unless the reader pastes the URL. Worth asking the Help Center owners for a prefill parameter we can pass.
2. This is coupled to Mintlify's DOM (.feedback-toolbar and the GitHub anchors). If Mintlify restructures the toolbar the button silently stops appearing. That degrades to today's behaviour rather than breaking a page, but nothing will alert us.

Layout (second and third commits)

Adding a third button pushed the toolbar past the width it had to spare. Mintlify groups it as [question] [[thumbs] [links]], where both inner groups are unbreakable flex items, so the question, the thumbs and the links each landed on a line of their own — and at 375px the link group was 508px wide, giving every docs page a horizontal scrollbar on mobile.

assets/feedback-support-ticket.css drops the thumbs/links wrapper out of the layout with display: contents, so the thumbs sit beside the question. The links keep their own wrapper and gain flex-wrap, so they stay one group that wraps together and wraps internally rather than overflowing the viewport.

The two groups are separated by 36px when they share a line, against 12px within a group. "Yes" and "No" answer "Was this page helpful?" and belong with it; suggesting an edit, raising an issue or opening a ticket are independent of that answer. Production drew the same distinction via justify-between. Below 640px the extra margin is dropped — there the links always wrap to their own line, and the margin only pushed the question off the thumbs' line.

Measured on this branch's preview deploy:

Toolbar width	Result
960px	One line; gaps 12 / 12 / 36 / 12 / 12
632px (the common case, with the right-hand TOC)	Row 1 question + thumbs, row 2 the three links as a group
375px viewport	No horizontal overflow (was 528px scroll width)

Note: this relies on CSS :has(), which is baseline across current browsers. Where it is unsupported the toolbar falls back to the stacked layout — nothing breaks.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
cometchat	🟢 Ready	View Preview	Aug 22, 2026, 3:55 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.