Skip to content

fix: cap Rating widget maxCount to 100 to prevent browser crash (#14833)#41897

Open
Piyush0049 wants to merge 2 commits into
appsmithorg:releasefrom
Piyush0049:fix/rating-widget-max-value-crash
Open

fix: cap Rating widget maxCount to 100 to prevent browser crash (#14833)#41897
Piyush0049 wants to merge 2 commits into
appsmithorg:releasefrom
Piyush0049:fix/rating-widget-max-value-crash

Conversation

@Piyush0049

@Piyush0049 Piyush0049 commented Jun 13, 2026

Copy link
Copy Markdown

Description

When a large number (e.g., 1000000) is provided as the max value for the Rating widget — either hardcoded or via data binding — the browser attempts to render millions of SVG star elements, causing an "Aw, snap!" crash with no way to recover.

Based on the requirements outlined by @dilippitchika in the issue comments:

  1. Property pane validation: Added max: 100 to the maxCount validation params so the property pane shows an error for values greater than 100.
  2. Render-time safety: Capped maxCount to 100 in getWidgetView() using Math.min() to safely handle data-binding edge cases where the bound value exceeds 100.

Fixes #14833

Automation

/ok-to-test tags=""

🔍 Cypress test results

Caution

If you modify the content in this section, you are likely to disrupt the CI result for your PR.

Communication

Should the DevRel and Marketing teams inform users about this change?

  • Yes
  • No

Summary by CodeRabbit

  • Bug Fixes
    • Rate Widget now enforces a maximum count limit of 100. Property pane validation prevents entering higher values, and the widget automatically caps any configured values above this threshold. This ensures consistent display and predictable behavior across the UI, avoiding unexpected counts and configuration errors.

…mithorg#14833)

When a large number (e.g., 1000000) is provided as the max value for the Rating widget, the browser attempts to render millions of SVG star elements, causing an 'Aw, snap!' crash.

Changes:

- Added max: 100 to maxCount property validation to show an error in the property pane for values > 100

- Capped maxCount to 100 in getWidgetView() to safely handle data-binding edge cases where the bound value exceeds 100
@coderabbitai

coderabbitai Bot commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: cdddf607-45d5-4cd1-95be-bd939606c156

📥 Commits

Reviewing files that changed from the base of the PR and between 531a02b and 5fc4877.

📒 Files selected for processing (1)
  • app/client/src/widgets/RateWidget/widget/index.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
  • app/client/src/widgets/RateWidget/widget/index.tsx

Walkthrough

RateWidget now enforces a maximum count of 100: property-pane validation rejects values >100, and runtime rendering clamps the value with Math.min(this.props.maxCount || 5, 100) before passing it to RateComponent.

Changes

RateWidget maxCount Capping

Layer / File(s) Summary
maxCount validation and capping
app/client/src/widgets/RateWidget/widget/index.tsx
Property validation schema enforces max: 100, and getWidgetView computes safeMaxCount via `Math.min(this.props.maxCount

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

⭐ A hundred stars, the limit set,
Calm renders now where chaos met,
Small clamp, big peace, the UI sings—
Safety tucked in tiny things.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely describes the main fix: capping the Rating widget's maxCount to 100 to prevent browser crashes.
Description check ✅ Passed The description comprehensively addresses the problem, solution details (property pane validation and render-time safety), and references the linked issue #14833.
Linked Issues check ✅ Passed The changes directly address issue #14833 by implementing both property pane validation (max: 100) and render-time safety (Math.min capping), preventing browser crashes from large maxCount values.
Out of Scope Changes check ✅ Passed All changes in the RateWidget are scoped to addressing the maxCount capping requirement from issue #14833; no out-of-scope modifications detected.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
app/client/src/widgets/RateWidget/widget/index.tsx (1)

164-177: ⚠️ Potential issue | 🟠 Major

Cap maxCount in RateWidget sizing to match the 100-star render cap

static getAutoLayoutConfig() / static getAnvilConfig() compute minWidth from the raw props.maxCount, but getWidgetView() clamps it via const safeMaxCount = Math.min(this.props.maxCount || 0, 100) before rendering. If a bound/runtime maxCount exceeds 100, the widget can be laid out wider than what actually renders.

Proposed fix

For getAutoLayoutConfig():

         configuration: (props: RateWidgetProps) => {
           let maxCount = props.maxCount;

           if (typeof maxCount !== "number")
             // TODO: Fix this the next time the file is edited
             // eslint-disable-next-line `@typescript-eslint/no-explicit-any`
             maxCount = parseInt(props.maxCount as any, 10);
+          
+          // Cap maxCount to prevent excessive sizing
+          maxCount = Math.min(maxCount, 100);

           return {
             // 21 is the size of a star, 5 is the margin between stars
             minWidth: `${maxCount * 21 + (maxCount + 1) * 5}px`,
             minHeight: "40px",
           };
         },

For getAnvilConfig():

       widgetSize: (props: RateWidgetProps) => {
         let maxCount = props.maxCount;

         if (typeof maxCount !== "number")
           // TODO: Fix this the next time the file is edited
           // eslint-disable-next-line `@typescript-eslint/no-explicit-any`
           maxCount = parseInt(props.maxCount as any, 10);
+        
+        // Cap maxCount to prevent excessive sizing
+        maxCount = Math.min(maxCount, 100);

         return {
           maxHeight: {},
           maxWidth: {},
           minHeight: { base: "40px" },
           minWidth: { base: `${maxCount * 21 + (maxCount + 1) * 5}px` },
         };
       },
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/client/src/widgets/RateWidget/widget/index.tsx` around lines 164 - 177,
The layout config uses the raw props.maxCount to compute minWidth causing
oversized layout when runtime maxCount > 100; in the configuration function used
by static getAutoLayoutConfig() and static getAnvilConfig(), parse/normalize
props.maxCount as you already do but then clamp it with const safeMaxCount =
Math.min(Number(parsedMaxCount)||0, 100) (preserve the existing parseInt
fallback behavior if needed) and use safeMaxCount in the minWidth/minHeight
calculations instead of maxCount so sizing matches the 100-star render cap used
by getWidgetView().
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@app/client/src/widgets/RateWidget/widget/index.tsx`:
- Line 478: Replace the current safeMaxCount calculation so it falls back to 5
instead of 0 and treats 0 as a valid value: change the assignment of
safeMaxCount to use nullish coalescing on this.props.maxCount and then clamp to
100, e.g. set safeMaxCount = Math.min(this.props.maxCount ?? 5, 100); this
preserves 0 as a valid input while using 5 when maxCount is null/undefined.

---

Outside diff comments:
In `@app/client/src/widgets/RateWidget/widget/index.tsx`:
- Around line 164-177: The layout config uses the raw props.maxCount to compute
minWidth causing oversized layout when runtime maxCount > 100; in the
configuration function used by static getAutoLayoutConfig() and static
getAnvilConfig(), parse/normalize props.maxCount as you already do but then
clamp it with const safeMaxCount = Math.min(Number(parsedMaxCount)||0, 100)
(preserve the existing parseInt fallback behavior if needed) and use
safeMaxCount in the minWidth/minHeight calculations instead of maxCount so
sizing matches the 100-star render cap used by getWidgetView().
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 94edf28f-e58f-472a-9a62-e2010a58b711

📥 Commits

Reviewing files that changed from the base of the PR and between 057cc61 and 531a02b.

📒 Files selected for processing (1)
  • app/client/src/widgets/RateWidget/widget/index.tsx

Comment thread app/client/src/widgets/RateWidget/widget/index.tsx Outdated
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]-[12]:"Aw, snap!" error when rating widget is provided a large number as max value

1 participant