fix(public): render the signup rejection signal on the homepage - #111
Conversation
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reached
Next review available in: 59 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (2)
ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe signup flow now redirects invalid email submissions with ChangesInvalid signup signal
Estimated code review effort: 2 (Simple) | ~10 minutes Mergeability Score: ⚪ Minimal · up to The change makes rejected signups show an accessible homepage message and cleans up the rejection URL; no actionable merge-blocking risk remains after normal checks and review. Sequence Diagram(s)sequenceDiagram
participant SignupRequest
participant AgentWorker
participant Browser
SignupRequest->>AgentWorker: Submit invalid email
AgentWorker->>Browser: Redirect to /?signal=invalid
Browser->>Browser: Read signal=invalid
Browser->>Browser: Reveal and focus signal-invalid
Browser->>Browser: Remove query string with history.replaceState
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c87126d733
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| var match=(location.search||'').match(/[?&]signal=([^&]+)/); | ||
| if(!match)return; |
There was a problem hiding this comment.
The handler checks only that a nonempty signal parameter exists, so /?signal=saved or /?signal=anything displays the invalid-email alert. This particularly affects successful-submission URLs retained in history from when htmlRedirect() used the saved signal; validate that the decoded parameter is exactly invalid before revealing the banner.
Useful? React with 👍 / 👎.
| <div class="orn"><i></i><span class="sc">The appraisal</span><b></b><i></i></div> | ||
| <h1>Most of them leave <em>before they ever get in touch.</em></h1> | ||
| <p class="sub">We read the one page your revenue depends on the way a customer with intent reads it, and show you the exact points at which they go.</p> | ||
| <p class="signal" id="signal-invalid" role="alert" tabindex="-1" hidden>We could not save that request — the email address did not pass. Check it and try again.</p> |
There was a problem hiding this comment.
When JavaScript is disabled or index.js fails to load, an invalid HTML form submission still redirects through htmlRedirect() to /?signal=invalid, but this element remains hidden forever, leaving the same silent bounce this change is intended to fix. The native form and Worker explicitly support no-JavaScript submissions, so the redirected response needs a server-rendered or <noscript> rejection message rather than relying exclusively on script to remove hidden.
Useful? React with 👍 / 👎.
The worker 303-redirects a rejected signup back to /?signal=invalid (its email regex is stricter than the browser's type=email check — 'a@b' passes client-side but not server-side), but no page code ever read that signal: the visitor was silently bounced to the homepage with zero feedback and their input gone. Reveal a role=alert banner when ?signal= invalid lands, focus it for assistive tech, then strip the query so a refresh or a copied link does not re-show the error. Deterministic source guards in check-site.mjs keep the banner, the handler and the worker redirect wired together, and a worker test locks the 303 -> /?signal=invalid contract and that rejected signups persist no row.
c87126d to
1aa08c5
Compare
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: afbbee3df8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| form button:hover{transform:translateY(-1.5px)} | ||
| .signal{display:block;margin:18px auto 0;max-width:500px;padding:10px 18px;font-size:14px;line-height:1.6; | ||
| color:var(--sig);background:rgba(255,253,248,.74);border:1px solid rgba(176,74,46,.35); | ||
| border-radius:12px;text-align:center} |
There was a problem hiding this comment.
When a sighted keyboard user submits an email rejected by the server, index.js moves focus to this banner, but this rule removes the only focus indicator without providing an alternative. The user therefore cannot visually determine where focus landed after the redirect; keep the outline or replace it with an equally visible :focus treatment.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e1a36091d9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (!homeScript.includes("signal-invalid")) { | ||
| failures.push("index.js must reference the signal-invalid banner."); | ||
| } | ||
| if (!/signal=([^&]+)/.test(homeScript)) { | ||
| failures.push("index.js must read the ?signal= query parameter."); |
There was a problem hiding this comment.
These checks never verify that the banner is revealed or focused, so a regression such as changing banner.hidden=false to banner.hidden=true while leaving the query parsing and element lookup intact still passes npm test; the worker test only covers the redirect, meaning invalid submissions can silently lose their feedback again with a green suite. Add a behavioral DOM test or source assertions that specifically cover the reveal and focus operations.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
1 participant
What
The worker 303-redirects a rejected signup back to /?signal=invalid (its email regex is stricter than the browser's type=email check — 'a@b' passes client-side but not server-side), but no page code ever read that signal. A visitor whose email the server rejected was silently bounced to the homepage with zero feedback: no banner, no alert, no explanation, and their input gone.
Verified live (2026-08-11, real Chromium): submitting a@b -> 303 -> https://tinystudio.io/?signal=invalid renders with feedback: {msgs: [], hasBanner: false}.
Fix
Validation
Note: wrangler deploy --dry-run fails in this worktree with 'Unexpected end of file in JSON' on ../../../package.json — reproduced identically on clean origin/main in the same worktree layout (wrangler resolves the project root relative to the nested worktree path); the change touches no JSON and CI's shallow checkout does not hit it.
Summary by CodeRabbit
New Features
Bug Fixes
Tests