✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

✅ PR preview is ready!

• New styling for remaining dropdowns (select all 5) #13798
• New styling for date and time widgets (select all 4) #13797
• New styling for selectbox and multiselect (select all 3) #13796
• Add select all and select x matches (select all 2) #13795 👈 (View in Graphite)
• Define selection constants (select all 1) #13794
• develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

Summary

This PR adds a "Select all" and "Select X matches" feature to the Multiselect widget. When the dropdown is open:

• Without a search filter: Shows "Select all" option to select all remaining unselected options
• With a search filter: Shows "Select X matches" option to select all filtered matches

The implementation is clean and the unit tests are comprehensive.

Code Quality

The implementation in Multiselect.tsx is well-structured:

1. Good separation of concerns: The filterOptions callback handles the UI logic of when to show "Select all" vs "Select X matches", while the generateNewState callback handles the actual selection logic.

2. Proper use of refs: The selectMatchesRef is used to store filtered matches for the "Select X matches" option, avoiding race conditions that could occur if the values were computed inline.

3. Edge case handling: The code correctly handles:

   • Only shows bulk selection options when there are >1 selectable options
   • Respects maxSelections limit
   • Distinguishes between search vs. no-search states

4. Reuses existing constants: Uses SELECT_ALL_ID and SELECT_MATCHES_ID from the shared Dropdown component, maintaining consistency.

Minor observation in Multiselect.tsx:244-255:

• The filtering logic stores values in selectMatchesRef on every filter call. This is necessary due to the callback-based architecture, but the comment accurately explains this design decision.

Test Coverage

Unit Tests (Frontend)

The unit test coverage is excellent:

1. Comprehensive new test suite: The "Select all and Select X matches" test suite (Multiselect.test.tsx:611-897) covers:

   • Selecting all from empty state
   • Selecting all when some options are already selected
   • Selecting matching options with search filter
   • maxSelections being respected for both "Select all" and "Select X matches"
   • Edge cases (0 options, 1 option, clearing search)
   • Mutually exclusive behavior (never shows both "Select all" and "Select X matches")

2. Existing tests updated correctly: Tests that check dropdown options now account for the new "Select all" option being first in the list.

3. Good negative assertions: Tests verify that "Select all" and "Select X matches" do NOT appear in inappropriate situations.

E2E Tests

Missing E2E test coverage: The PR does not include E2E tests for the new feature. While the unit tests are comprehensive, E2E tests would verify:

• Visual appearance of "Select all" option
• Integration with the full Streamlit stack
• Behavior across different browsers

Potential E2E test breakage: Some existing E2E tests may fail due to the new "Select all" option changing dropdown item counts:

• st_multiselect_test.py:157 - expect(dropdown_elements).to_have_count(2) expects exactly 2 items for a 2-option multiselect. With "Select all", this would be 3.
• st_multiselect_test.py:379 - expect(options_list).to_have_count(4) may need adjustment.

Backwards Compatibility

Low risk of breaking changes:

• The feature is purely additive - existing functionality is preserved
• The "Select all" option only appears when there are 2+ selectable options
• Single-option multiselects behave exactly as before
• The order preservation of existing options is maintained (new option is prepended)

One subtle behavioral change: Users who relied on the first dropdown item being the first data option will now see "Select all" first. This is unlikely to cause issues in practice.

Security & Risk

No security concerns identified:

• The feature operates entirely on existing option data
• No new user input handling that could introduce XSS or injection vulnerabilities
• The SELECT_ALL_ID and SELECT_MATCHES_ID are internal constants, not exposed to users

Low regression risk:

• The core selection logic in generateNewState is extended with new cases but existing cases are untouched
• The filtering logic is isolated in filterOptions

Recommendations

1. Verify E2E tests pass: Run the existing E2E tests to confirm they still pass with the new "Select all" option. If not, update the expected counts:

   • st_multiselect_test.py:157 may need to change from to_have_count(2) to to_have_count(3)
   • Similar adjustments may be needed elsewhere

2. Consider adding E2E test coverage: Add at least one E2E test for the "Select all" functionality to catch visual regressions:

   def test_multiselect_select_all(app: Page):
       """Should select all options when clicking Select all."""
       ms = get_multiselect(app, "multiselect 1")
       ms.locator("input").click()
       app.locator("li").filter(has_text="Select all").click()
       wait_for_app_run(app)
       expect_text(app, "value 1: ['male', 'female']")

3. Add snapshot test for dropdown with "Select all": Consider adding a screenshot test showing the "Select all" option in the dropdown.

4. PR description is sparse: The PR body template fields (Testing Plan, etc.) are not filled in. Adding details about the testing approach would help reviewers.

Verdict

APPROVED: The implementation is clean, well-tested with comprehensive unit tests, and follows existing patterns. The feature adds valuable UX improvement without breaking existing functionality. The main gap is missing E2E test updates/additions, which should be verified before merge to ensure CI passes.

This is an automated AI review using opus-4.5-thinking. Please verify the feedback and use your judgment.

📈 Frontend coverage change detected

The frontend unit test (vitest) coverage has increased by 0.0900%

• Current PR: 87.0700% (14042 lines, 1815 missed)
• Latest develop: 86.9800% (14033 lines, 1826 missed)

🎉 Great job on improving test coverage!

📊 View detailed coverage comparison

Merge activity

• Feb 16, 9:33 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Feb 16, 9:34 PM UTC: Graphite couldn't merge this pull request because a downstack PR Define selection constants (select all 1) #13794 failed to merge.
• Feb 16, 11:04 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Feb 16, 11:06 PM UTC: Graphite rebased this pull request as part of a merge.
• Feb 16, 11:23 PM UTC: Graphite couldn't merge this PR because it was not satisfying all requirements (Failed CI: 'playwright-e2e-tests').
• Feb 16, 11:48 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Feb 16, 11:49 PM UTC: @sfc-gh-dmatthews merged this pull request with Graphite.

I don't agree to "Users who relied on the first dropdown item being the first data option will now see "Select all" first. This is unlikely to cause issues in practice.".

In my case there are hundreds of options, and selecting all of them may cause a huge amount of data to be loaded, potentially crashing the Streamlit Server.

How can we switch off the new feature?