fix(grok): fall back to Enter-key dispatch when submit button never appears (#1782)#1808
Merged
Merged
Conversation
jackwener
force-pushed
the
fix/grok-ask-enter-key
branch
2 times, most recently
from
ae140a9 to
c093fa6
Compare
…ppears Closes jackwener#1782. Some Grok deployments / locales never surface a `button[aria-label="Submit"]` after the prompt is inserted — the composer is functional and the assistant is reachable via the Enter key, but `sendMessage()` would fail with: "Grok submit button did not reach a clickable state after prompt insertion." Keep the existing submit-button click as the primary path (it is the cleanest signal that Grok is ready to accept the prompt). When the 12-attempt poll exhausts without finding a clickable button, dispatch a full keydown + keypress + keyup chain for `Enter` on the active focus target before declaring failure. This mirrors the `opencli browser grok type "..."` + Enter workaround documented in the issue. The return shape now reports which path was used (`submittedVia: 'submit-button'` vs `'enter-key'`), so downstream callers can log the fallback without breaking the existing `{ ok: true }` contract. Existing tests still pass (clis/grok/{ask,utils,image}.test.* — 29 assertions). No new unit tests added because the fallback only manifests inside `page.evaluate(...)` against a live Grok page; E2E coverage for this path will fall under tests/e2e/browser-auth.test.ts when an explicit Grok scenario is added.
jackwener
force-pushed
the
fix/grok-ask-enter-key
branch
from
c093fa6 to
b178eb3
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #1782.
grok askwas failing with:```
Grok submit button did not reach a clickable state after prompt insertion.
```
on some Grok deployments / locales where `button[aria-label="Submit"]` never appears. The composer is fully functional (the user's documented workaround is `opencli browser grok type "hello\n"`), so we just need an Enter-key fallback.
Change
Keep the existing button-click as the primary path (cleanest readiness signal). When the 12-attempt poll exhausts:
Return shape gains `submittedVia: 'submit-button' | 'enter-key'` so downstream callers can log which path won, without breaking the existing `{ ok: true }` contract.
Tests
Existing `clis/grok/{ask,utils,image}.test.*` pass (29/29). No new unit tests — the fallback only manifests inside `page.evaluate(...)` against a live Grok page. E2E coverage belongs in `tests/e2e/browser-auth.test.ts` when an explicit Grok scenario is added (currently the file covers bilibili / twitter / v2ex / xueqiu / linux-do / xiaohongshu but not Grok).
Verification path
```bash
opencli grok ask "hello" # before: fails; after: returns response (via either path)
```