-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Revert "Revert "feat: Added focus ring for focus visible (#37700)" (#… #38655
Conversation
WalkthroughThis pull request focuses on enhancing focus styles and accessibility across various components in the design system. The changes primarily involve modifying how focus states are rendered, transitioning from border-based to outline-based styles, and ensuring consistent focus visibility across different UI elements. The modifications span multiple files in the design system and application components, with a particular emphasis on improving keyboard navigation and visual feedback. Changes
Possibly related PRs
Suggested Labels
Suggested Reviewers
Poem
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
⏰ Context from checks skipped due to timeout of 90000ms (11)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (3)
app/client/src/components/propertyControls/IconSelectControlV2.tsx (1)
56-59
: Focus state implementation follows modern accessibility practices.The transition from
&:focus
to&:focus-visible
with outline-based focus indicators improves keyboard navigation accessibility while preventing unnecessary focus rings during mouse interactions.Consider documenting these focus management patterns in your design system guidelines to ensure consistency across components.
app/client/packages/design-system/ads/src/Button/Button.tsx (1)
46-47
: Improve click handler implementation.The current implementation could be more explicit about the disabled state.
Consider this implementation:
- const handleClick = - props.isLoading || props.isDisabled ? undefined : props.onClick; + const handleClick = (event: React.MouseEvent<HTMLButtonElement>) => { + if (!props.isLoading && !props.isDisabled && props.onClick) { + props.onClick(event); + } + };Also applies to: 56-56
app/client/src/components/propertyControls/ColorPickerComponentV2.tsx (1)
Line range hint
1-577
: Consider adding keyboard interaction documentationThe component has extensive keyboard navigation support but lacks documentation about the supported keyboard shortcuts and interactions.
Add JSDoc comments at the component level to document the keyboard interactions:
+/** + * Color picker component with keyboard navigation support. + * + * Keyboard interactions: + * - Enter: Opens color picker / Selects color + * - Escape: Closes color picker / Blurs input + * - Arrow keys: Navigate through colors + * - Tab: Navigate through focusable elements + */ const ColorPickerComponent = React.forwardRef(
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (18)
app/client/packages/design-system/ads-old/src/SearchComponent/index.tsx
(1 hunks)app/client/packages/design-system/ads/src/Button/Button.styles.tsx
(2 hunks)app/client/packages/design-system/ads/src/Button/Button.tsx
(4 hunks)app/client/packages/design-system/ads/src/Input/Input.styles.tsx
(3 hunks)app/client/packages/design-system/ads/src/Input/Input.tsx
(3 hunks)app/client/packages/design-system/ads/src/Link/Link.styles.tsx
(1 hunks)app/client/packages/design-system/ads/src/SegmentedControl/SegmentedControl.styles.tsx
(1 hunks)app/client/packages/design-system/ads/src/Select/styles.css
(3 hunks)app/client/packages/design-system/ads/src/Switch/Switch.styles.tsx
(1 hunks)app/client/packages/design-system/ads/src/Tab/Tab.styles.tsx
(1 hunks)app/client/packages/design-system/ads/src/Text/Text.styles.tsx
(1 hunks)app/client/packages/design-system/ads/src/__theme__/default/index.css
(2 hunks)app/client/src/components/editorComponents/CodeEditor/index.tsx
(1 hunks)app/client/src/components/editorComponents/CodeEditor/styledComponents.ts
(3 hunks)app/client/src/components/propertyControls/ColorPickerComponentV2.tsx
(1 hunks)app/client/src/components/propertyControls/IconSelectControl.tsx
(1 hunks)app/client/src/components/propertyControls/IconSelectControlV2.tsx
(1 hunks)app/client/src/index.css
(0 hunks)
💤 Files with no reviewable changes (1)
- app/client/src/index.css
⏰ Context from checks skipped due to timeout of 90000ms (9)
- GitHub Check: perform-test / rts-build / build
- GitHub Check: client-unit-tests / client-unit-tests
- GitHub Check: client-lint / client-lint
- GitHub Check: client-check-cyclic-deps / check-cyclic-dependencies
- GitHub Check: client-build / client-build
- GitHub Check: client-prettier / prettier-check
- GitHub Check: chromatic-deployment
- GitHub Check: chromatic-deployment
- GitHub Check: storybook-tests
🔇 Additional comments (26)
app/client/src/components/propertyControls/IconSelectControlV2.tsx (1)
56-59
: Verify keyboard navigation with new focus styles.The extensive keyboard navigation implementation needs verification with the new focus styles, particularly for:
- Arrow key navigation
- Tab key behavior
- Enter/Space key selection
Let's verify the keyboard navigation implementation:
Also applies to: 269-365
✅ Verification successful
Keyboard navigation implementation verified successfully
The focus styles and keyboard navigation implementation follow accessibility best practices and design system guidelines.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other components using similar keyboard navigation patterns # to ensure consistent focus handling # Look for keyboard event handlers rg -l "ArrowDown|ArrowUp|ArrowLeft|ArrowRight" --type ts --type tsx # Check for focus-visible usage across the codebase rg "&:focus-visible" --type css --type styled-componentsLength of output: 198
Script:
#!/bin/bash # Search for keyboard navigation patterns rg "onKeyDown|onKeyUp|KeyboardEvent" --type ts # Search for arrow key constants and handlers rg "ArrowDown|ArrowUp|ArrowLeft|ArrowRight" # Look for focus-visible styles rg ":focus-visible|&:focus-visible" # Search for accessibility-related keyboard handlers rg "role=.*button.*onKeyDown|role=.*menu.*onKeyDown"Length of output: 130543
app/client/packages/design-system/ads/src/Tab/Tab.styles.tsx (1)
91-92
: LGTM! Consistent focus ring implementation.The use of design tokens and !important flags ensures focus styles are consistently visible, improving accessibility.
app/client/packages/design-system/ads/src/SegmentedControl/SegmentedControl.styles.tsx (1)
70-71
: LGTM! Consistent with design system focus styles.The implementation matches the focus ring pattern used across other components.
app/client/packages/design-system/ads/src/Switch/Switch.styles.tsx (1)
75-77
: LGTM! Enhanced focus management with React Aria.The implementation correctly uses isFocusVisible from React Aria while maintaining consistent focus styles.
Please ensure keyboard navigation works as expected:
app/client/packages/design-system/ads/src/Button/Button.tsx (2)
21-23
: LGTM! Good extraction of spinner icon props.Moving the icon props to a constant improves maintainability.
50-50
: LGTM! Proper focus ring implementation.Good use of React Aria's useFocusRing hook for managing focus states. The implementation correctly passes both focusProps and isFocusVisible to the styled component.
Verify focus ring behavior across browsers:
Also applies to: 57-57, 64-64
app/client/packages/design-system/ads-old/src/SearchComponent/index.tsx (1)
66-70
: LGTM! Focus styles follow accessibility best practices.The transition to outline-based focus styles with proper offset improves keyboard navigation visibility.
app/client/packages/design-system/ads/src/Link/Link.styles.tsx (1)
94-95
: LGTM! Ensuring focus styles take precedence.The !important declarations are justified here to guarantee focus visibility for accessibility.
app/client/packages/design-system/ads/src/Input/Input.tsx (1)
69-74
: LGTM! Performance optimization with useCallback.Memoizing the onChange handler prevents unnecessary re-renders.
app/client/packages/design-system/ads/src/Input/Input.styles.tsx (2)
167-167
: LGTM! Improved padding calculations.The padding calculations correctly account for icon sizes and border width.
Also applies to: 177-177
204-208
: LGTM! Consolidated focus styles.Focus styles are properly centralized and follow accessibility best practices.
app/client/packages/design-system/ads/src/Text/Text.styles.tsx (2)
Line range hint
57-57
: Good addition of theshowFocusVisible
prop for conditional focus styles.The implementation properly uses design system variables for consistent focus indicators.
Also applies to: 87-96
207-212
: Well-implemented focus-visible styles for the input.The outline properties are correctly using design system variables for consistent focus indicators.
app/client/packages/design-system/ads/src/Button/Button.styles.tsx (1)
213-213
: Good implementation of conditional focus styles.The focus ring implementation properly uses:
- Conditional rendering based on
isFocusVisible
- Design system variables for consistent styling
- Appropriate use of !important for focus styles
Also applies to: 273-281
app/client/src/components/editorComponents/CodeEditor/styledComponents.ts (2)
57-57
: Well-structured focus management for CodeMirror.The implementation correctly:
- Uses conditional focus styles
- Handles z-index for proper focus visibility
- Maintains consistency with design system variables
Also applies to: 87-96
405-409
: Good transition to focus-visible for CodeEditorTarget.The outline styles properly follow accessibility best practices.
app/client/src/components/propertyControls/IconSelectControl.tsx (1)
55-58
: Good transition to focus-visible for icon selection.The implementation properly uses design system variables for consistent focus indicators.
app/client/packages/design-system/ads/src/Select/styles.css (3)
3-6
: LGTM! Improved comment organization.Comments are now properly aligned with their respective CSS variables, enhancing code readability.
Line range hint
91-99
: LGTM! Proper spacing calculation for multiple icons.The padding calculation now correctly accounts for both clear and arrow icons (20px + 16px), preventing text overlap.
118-120
: LGTM! Prevents layout shift during focus.Using transparent border color on focus prevents the component from shifting when the outline is applied.
app/client/packages/design-system/ads/src/__theme__/default/index.css (3)
242-244
: LGTM! Well-defined focus variables.Using semantic color tokens (
--ads-v2-color-blue-300
) for focus outline maintains design system consistency.
260-261
: LGTM! Robust focus ring implementation.Using !important ensures focus styles are consistently applied across the application, overriding any conflicting styles.
254-256
: Verify the impact of removing global focus outlines.Removing all focus outlines globally might affect accessibility. Ensure that all interactive elements have proper focus indicators through the
ads-v2-focus-ring
class.✅ Verification successful
Global focus outline removal is properly compensated
The codebase consistently uses react-aria's
useFocusRing
with custom focus styles across all interactive components (Button, Checkbox, Radio, Switch, Input). The removal of the global outline is intentional and properly handled through the design system's focus management implementation.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for interactive elements without focus-ring class rg -l "tabIndex|role=\"button\"|<button" | xargs rg -L "ads-v2-focus-ring"Length of output: 72
Script:
#!/bin/bash # Search for interactive elements in JSX/TSX files echo "=== Interactive elements ===" rg -t tsx -t jsx -t js "onClick|onKeyDown|tabIndex|role=|<button|<a\s|<input|<select" -l # Check focus ring implementation echo -e "\n=== Focus ring implementation ===" rg "ads-v2-focus-ring" -A 3 -B 3 # Check if focus ring is defined in CSS echo -e "\n=== Focus ring CSS ===" rg "\.ads-v2-focus-ring" -A 5 -B 1 -t cssLength of output: 1846
Script:
#!/bin/bash # Search for interactive elements with correct file types echo "=== Interactive elements ===" rg --type js --type jsx "onClick|onKeyDown|tabIndex|role=|<button|<a\s|<input|<select" -l # Check useFocusRing usage echo -e "\n=== useFocusRing usage ===" rg "useFocusRing|isFocusVisible" -A 2 -B 2Length of output: 11249
app/client/src/components/editorComponents/CodeEditor/index.tsx (1)
1797-1797
: LGTM! Conditional focus visibility.The
showFocusVisible
prop correctly disables focus ring for JS objects while maintaining it for other editor instances.app/client/src/components/propertyControls/ColorPickerComponentV2.tsx (2)
98-102
: Great accessibility improvement with focus-visible!The switch from
:focus
to:focus-visible
enhances keyboard navigation while preventing unnecessary focus rings during mouse interactions.
Line range hint
104-109
: LGTM: Clean hover state implementationThe hover state is now properly separated from focus state and maintains consistent styling with the design system using CSS custom properties.
@@ -55,7 +54,7 @@ const Input = forwardRef<HTMLInputElement, InputProps>( | |||
const { descriptionProps, errorMessageProps, inputProps, labelProps } = | |||
// @ts-expect-error fix this the next time the file is edited | |||
useTextField(props, inputRef); | |||
const { focusProps, isFocusVisible } = useFocusRing(); | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix the type assertion.
The @ts-expect-error comment indicates a known type issue that needs to be addressed.
Consider fixing the type issue by:
- Adding proper types for useTextField hook
- Updating the component props interface
This PR has not seen activitiy for a while. It will be closed in 7 days unless further activity is detected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
app/client/cypress/e2e/Regression/ClientSide/PropertyPane/PropertyPane_Search_spec.ts (1)
Line range hint
127-128
: Replace CSS selector with data- attribute.*Using CSS selector
.t--property-control-onpagechange
goes against the coding guidelines. Consider using a data-* attribute instead.// Replace agHelper.AssertElementAbsence(".t--property-control-onpagechange"); // With agHelper.AssertElementAbsence(propPane._propertyControlOnPageChange);
🧹 Nitpick comments (2)
app/client/cypress/e2e/Regression/ClientSide/PropertyPane/PropertyPane_Search_spec.ts (1)
20-40
: Consider adding custom commands for focus assertions.The focus assertions might be flaky in CI. Consider creating custom commands that handle focus state verification more robustly.
Example approach:
// In commands.ts Cypress.Commands.add('assertFocusState', (selector: string) => { cy.get(selector) .should('be.visible') .and('have.focus') .then($el => { expect(document.activeElement).to.eq($el[0]); }); });app/client/src/pages/Editor/PropertyPane/PropertyPaneSearchInput.tsx (1)
Line range hint
35-54
: Consider refactoring the focus management logic.The current implementation has potential issues:
- Using setTimeout for focus management could lead to race conditions
- The 300ms delay is a magic number
- The conditional logic is complex and could be simplified
Consider this alternative approach:
- setTimeout( - () => { - inputRef.current?.focus(); - }, - isPanel ? 300 : 0, - ); + const PANEL_TRANSITION_DELAY = 300; + const focusInput = () => inputRef.current?.focus(); + if (isPanel) { + window.requestAnimationFrame(() => { + setTimeout(focusInput, PANEL_TRANSITION_DELAY); + }); + } else { + focusInput(); + }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
app/client/cypress/snapshots/Regression/ClientSide/VisualTests/JSEditorIndent_spec.js/formattedJSONBodyAfterSave.snap.png
is excluded by!**/*.png
📒 Files selected for processing (2)
app/client/cypress/e2e/Regression/ClientSide/PropertyPane/PropertyPane_Search_spec.ts
(1 hunks)app/client/src/pages/Editor/PropertyPane/PropertyPaneSearchInput.tsx
(3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
app/client/cypress/e2e/Regression/ClientSide/PropertyPane/PropertyPane_Search_spec.ts (1)
Pattern app/client/cypress/**/**.*
: Review the following e2e test code written using the Cypress test library. Ensure that:
- Follow best practices for Cypress code and e2e automation.
- Avoid using cy.wait in code.
- Avoid using cy.pause in code.
- Avoid using agHelper.sleep().
- Use locator variables for locators and do not use plain strings.
- Use data-* attributes for selectors.
- Avoid Xpaths, Attributes and CSS path.
- Avoid selectors like .btn.submit or button[type=submit].
- Perform logins via API with LoginFromAPI.
- Perform logout via API with LogOutviaAPI.
- Perform signup via API with SignupFromAPI.
- Avoid using it.only.
- Avoid using after and aftereach in test cases.
- Use multiple assertions for expect statements.
- Avoid using strings for assertions.
- Do not use duplicate filenames even with different paths.
- Avoid using agHelper.Sleep, this.Sleep in any file in code.
⏰ Context from checks skipped due to timeout of 90000ms (9)
- GitHub Check: perform-test / ci-test-result
- GitHub Check: client-unit-tests / client-unit-tests
- GitHub Check: client-prettier / prettier-check
- GitHub Check: client-lint / client-lint
- GitHub Check: client-check-cyclic-deps / check-cyclic-dependencies
- GitHub Check: client-build / client-build
- GitHub Check: storybook-tests
- GitHub Check: chromatic-deployment
- GitHub Check: chromatic-deployment
🔇 Additional comments (5)
app/client/cypress/e2e/Regression/ClientSide/PropertyPane/PropertyPane_Search_spec.ts (3)
Line range hint
43-61
: LGTM! Well-structured search functionality tests.The test cases effectively cover different search scenarios and follow Cypress best practices.
Line range hint
63-77
: LGTM! Clean section visibility test implementation.Good practice using ClearTextField for cleanup between tests.
Line range hint
130-185
: LGTM! Comprehensive edge case coverage.Well-structured tests covering important edge cases and potential regression scenarios.
app/client/src/pages/Editor/PropertyPane/PropertyPaneSearchInput.tsx (2)
Line range hint
11-21
: LGTM! Clean styling approach.The simplified styling with sticky positioning ensures good UX while maintaining accessibility.
58-67
: Verify tabIndex necessity.The component uses explicit tabIndex values which might affect keyboard navigation:
- Container has tabIndex={-1}
- SearchInput has tabIndex={0}
Let's verify if these tabIndex values are necessary:
✅ Verification successful
tabIndex values are correctly implemented
The tabIndex implementation is necessary for proper focus management during property pane transitions and prevents UI jittering. The values are part of an intentional focus management strategy.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for similar patterns in the codebase to understand the tabIndex usage convention rg -A 2 'tabIndex={-1}' --type ts --type tsx rg -A 2 'tabIndex={0}' --type ts --type tsx # Check if there are any accessibility-related tests fd -e test.tsx -e test.ts -x rg -l 'accessibility|tabIndex|focus'Length of output: 1577
Script:
#!/bin/bash # Search for tabIndex patterns with escaped braces rg "tabIndex=\{-1\}" --type typescript rg "tabIndex=\{0\}" --type typescript # Check PropertyPane-related test files for accessibility testing rg -l "describe|test|it" ./app/client/src/pages/Editor/PropertyPane/PropertyPaneTitle.test.tsx # Look for accessibility-related comments or patterns rg "a11y|accessibility|keyboard|focus|tab" ./app/client/src/pages/Editor/PropertyPane/Length of output: 4853
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
app/client/src/pages/Editor/PropertyPane/PropertyPaneSearchInput.tsx (1)
Line range hint
38-49
: Simplify focus management logicThe current focus management implementation has several potential issues:
- Using setTimeout for focus management can be unreliable
- The condition checking isCurrentFocusOnInput is commented out but the code remains
- The panel transition timing is hardcoded
Consider using a more reliable focus management approach:
useEffect(() => { - if ( - shouldFocusSearch && - isPanel === shouldFocusPanelSearch - ) { - setTimeout( - () => { - if (!isCurrentFocusOnInput()) { - wrapperRef.current?.focus(); - } - }, - isPanel ? 300 : 0, - ); + if (shouldFocusSearch && isPanel === shouldFocusPanelSearch) { + // Use requestAnimationFrame for more reliable focus management + requestAnimationFrame(() => { + wrapperRef.current?.focus(); + }); } }, [shouldFocusSearch, shouldFocusPanelSearch, isPanel]);
🧹 Nitpick comments (1)
app/client/src/pages/Editor/PropertyPane/PropertyPaneSearchInput.tsx (1)
Line range hint
1-8
: Remove unused importisCurrentFocusOnInput
The import is no longer used in the component after recent changes.
- import { isCurrentFocusOnInput } from "utils/editorContextUtils";
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
app/client/src/pages/Editor/PropertyPane/PropertyPaneSearchInput.tsx
(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (9)
- GitHub Check: perform-test / server-build / server-unit-tests
- GitHub Check: perform-test / rts-build / build
- GitHub Check: client-lint / client-lint
- GitHub Check: client-build / client-build
- GitHub Check: client-check-cyclic-deps / check-cyclic-dependencies
- GitHub Check: client-prettier / prettier-check
- GitHub Check: chromatic-deployment
- GitHub Check: storybook-tests
- GitHub Check: chromatic-deployment
🔇 Additional comments (1)
app/client/src/pages/Editor/PropertyPane/PropertyPaneSearchInput.tsx (1)
Line range hint
92-98
: Review tab order for keyboard accessibilityThe current tabIndex configuration might create accessibility issues:
- The wrapper is focusable (tabIndex=0)
- The input itself is removed from the tab order (tabIndex=-1)
Please verify if this tab order is intentional and meets accessibility requirements. Consider:
<SearchInput className="propertyPaneSearch t--property-pane-search-input-wrapper" onChange={props.onTextChange} placeholder={PROPERTY_SEARCH_INPUT_PLACEHOLDER} ref={inputRef} - tabIndex={-1} />
/build-deploy-preview skip-test=true |
Deploying Your Preview: https://github.com/appsmithorg/appsmith/actions/runs/12982388180. |
Deploy-Preview-URL: https://ce-38655.dp.appsmith.com |
@@ -12,14 +12,15 @@ describe("Property Pane Search", { tags: ["@tag.PropertyPane"] }, function () { | |||
agHelper.AddDsl("swtchTableV2Dsl"); | |||
}); | |||
|
|||
it("1. Verify if the search Input is getting focused when a widget is selected", function () { | |||
// skipping this because this feature is not |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is not what? Do we even need this test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what I posted in channel where the soft focus behaviour for search input is there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Invalid image source.
Is this expected?
/build-deploy-preview skip-test=true |
Deploying Your Preview: https://github.com/appsmithorg/appsmith/actions/runs/13072183933. |
Deploy-Preview-URL: https://ce-38655.dp.appsmith.com |
…38650)"
This reverts commit e1b3b0d.
Description
Tip
Add a TL;DR when the description is longer than 500 words or extremely technical (helps the content, marketing, and DevRel team).
Please also include relevant motivation and context. List any dependencies that are required for this change. Add links to Notion, Figma or any other documents that might be relevant to the PR.
Fixes #
Issue Number
or
Fixes
Issue URL
Warning
If no issue exists, please create an issue first, and check with the maintainers if the issue is valid.
Automation
/ok-to-test tags="@tag.All"
🔍 Cypress test results
Tip
🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉
Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/13106069580
Commit: 7f7dcd2
Cypress dashboard.
Tags:
@tag.All
Spec:
Mon, 03 Feb 2025 05:27:48 UTC
Communication
Should the DevRel and Marketing teams inform users about this change?
Summary by CodeRabbit
Style Updates
outline
with!important
flag.Design System Refinements
CSS Improvements
PropertyPaneSearchInput
component.ColorPickerComponent
andIconSelectControl
components.