[AKzar1el]

Problem

The GPT-6 model-effort picker exposes an ARIA slider with a valid range and ticks, but effort discovery can repeatedly fail with ChatGPT did not move its effort slider toward the requested position. The previous implementation always sent ArrowLeft/Right to the ancestor role=menuitem; the actual slider thumb can own keyboard focus and events.

Change

• Prefer keyboard input on the focusable role=slider thumb; use the existing menu-item keyboard path for legacy/nonfocusable layouts.
• When keyboard input is ineffective, click the visible horizontal track at the requested position with the browser automation's real pointer interaction.
• Read back aria-valuenow after each attempt, preserving range/lock checks, abort handling and fail-closed behavior. Never assign ARIA values or infer an unobserved effort.
• Add independent real-Chrome fixtures for slider-only keyboard handlers and pointer-only sliders, including restoration to the original setting.

Verification

• Bun 1.4.4 TypeScript typecheck: passed.
• Browser-companion build: passed.
• Real-Chrome capability discovery/restoration: 3 passed, 0 failed, including slider-only and pointer-only fallback.
• Real-Chrome pairing regression: Medium selection/restoration passes across three model-family fixtures; tests retain the per-family 10 s budget.
• Full offline browser companion suite: 175 passed, 147 skipped; 1 unrelated existing Windows permission-mode assertion in connector-cache.test.ts fails because Windows reports 0666 instead of POSIX 0600.

The official production companion was not replaced. An independent native 2.3.29 capability probe did succeed, but the patched build still needs a controlled authenticated live trial before production deployment. No goal, shared tunnel, worker, or fleet schedule was modified.

[devnoname120]

How do you determine where to click on the horizontal slider? I don’t want anything that hardcodes the count of effort levels and the like