Description

RhOption.value's custom setter only updates a private field and never requests an update, so the
@observes('value') handler will not run and the cached displayLabel can become stale when value is
changed programmatically. This breaks the component’s own intended value→label sync logic.

Code

elements/rh-select/rh-option.ts[R41-48]

+  @property()
+  get value() {
+    return this.#value ?? this.displayLabel ?? '';
+  }
+
+  set value(v: string) {
+    this.#value = v;
+  }

Evidence

The component defines an @observes('value') hook to update the cached label when value changes, but
the value setter does not trigger Lit’s update cycle, so that observer won’t reliably fire for
programmatic assignments (e.g., option.value = 'x').

elements/rh-select/rh-option.ts[41-48]
elements/rh-select/rh-option.ts[149-159]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`<rh-option>` implements `value` as a custom accessor but its setter does not call `requestUpdate()`. As a result, updates to `value` made programmatically do not reliably participate in Lit reactivity, and the existing `@observes('value')` hook intended to keep `displayLabel` in sync may not run.
### Issue Context
The component already has `@observes('value')` to recompute the cached display label, but the setter currently only mutates `#value`.
### Fix Focus Areas
- elements/rh-select/rh-option.ts[41-48]
- elements/rh-select/rh-option.ts[155-159]
### Implementation notes
- Update the `set value(v: string)` implementation to capture the old value and call `this.requestUpdate('value', oldValue)`.
- Ensure attribute→property updates also trigger the same path (the accessor should remain reactive).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

RhOptionGroup caches its child options only once in firstUpdated(), so disabling/enabling the group
(or adding/removing options later) can leave some child rh-option elements with an incorrect
disabled state. This makes the UI state inconsistent and can allow selecting options that should be
disabled.

Code

elements/rh-select/rh-option-group.ts[R51-58]

+  override firstUpdated() {
+    if (!isServer) {
+      this.#optionEls = this.#getChildOptions();
+      if (this.disabled) {
+        this.#updateDisabledChildren();
+      }
+    }
+  }

Evidence

Child options are captured once into #optionEls during firstUpdated(), but subsequent disabled
changes only iterate that cached list; the code never refreshes #optionEls on slot changes, so
dynamically inserted options are never updated.

elements/rh-select/rh-option-group.ts[51-58]
elements/rh-select/rh-option-group.ts[72-95]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`<rh-option-group>` stores its child `<rh-option>` elements in a private cache (`#optionEls`) only once in `firstUpdated()`. If children are added/removed later, or if `disabled` is toggled after the child list changes, the group will not correctly propagate `disabled` to the current set of child options.
### Issue Context
The component already has a `#getChildOptions()` helper that reads from the default slot, but it is only used during `firstUpdated()`.
### Fix Focus Areas
- elements/rh-select/rh-option-group.ts[51-58]
- elements/rh-select/rh-option-group.ts[72-95]
### Implementation notes
- Add a `@slotchange` handler on the default slot to refresh `#optionEls` and then call `#updateDisabledChildren()`.
- or, simpler: in `disabledChanged()` (and/or `#updateDisabledChildren()`), recompute `this.#optionEls = this.#getChildOptions()` before iterating.
- Ensure the initial disabled state is applied even if options are slotted after first render.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

RhSelect.#onKeydown treats Space as a printable character and unconditionally calls
preventDefault()+stopPropagation(), routing Space into type-ahead. This conflicts with the
component’s own intent to intercept Space only during an active type-ahead session and can block
other Space-driven behaviors (open/select) handled elsewhere.

Code

elements/rh-select/rh-select.ts[R690-702]

+  #onKeydown(event: KeyboardEvent) {
+    // Only handle printable characters
+    const isPrintable = event.key.length === 1
+      && !event.ctrlKey
+      && !event.altKey
+      && !event.metaKey;
+
+    if (isPrintable) {
+      // Don't scroll after pressing space and don't toggle the listbox
+      event.preventDefault();
+      event.stopPropagation();
+      this.#handleTypeAhead(event.key);
+    }

Evidence

The capture-phase handler explicitly documents that Space should only be intercepted during an
active type-ahead session, but #onKeydown intercepts all printable keys (Space included) and stops
propagation every time, creating conflicting behavior and potentially preventing the normal Space
behavior when not in a type-ahead session.

elements/rh-select/rh-select.ts[219-235]
elements/rh-select/rh-select.ts[690-702]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`#onKeydown` currently classifies Space (`event.key === ' '`) as a printable character and always calls `preventDefault()` and `stopPropagation()`, sending it to `#handleTypeAhead()`. This contradicts the documented intent in `#captureKeydown` (only intercept Space during an active type-ahead session) and can interfere with Space’s normal meaning for combobox/select interactions.
### Issue Context
There are two different Space interception paths:
- `#captureKeydown` (capture phase) conditionally intercepts Space only when a type-ahead session is active.
- `#onKeydown` (bubble phase) intercepts Space unconditionally as “printable”.
### Fix Focus Areas
- elements/rh-select/rh-select.ts[219-235]
- elements/rh-select/rh-select.ts[690-702]
### Implementation notes
- Update `#onKeydown` to exclude Space from `isPrintable` (e.g., add `&& event.key !== ' '`).
- Keep Space handling in `#captureKeydown` for the specific “type-ahead in progress” case.
- Re-run/extend keyboard tests around Space to ensure open/select behavior remains correct.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools