feat(html): a tap opens a sheet cell's editor on a touch screen - #908
Merged
Merged
Conversation
Opening a cell took a double click, which a phone gives up two taps for and still reports as two separate taps first. The reader has already entered the mode that edits, so on a coarse pointer the first tap now opens the editor; a fine pointer keeps the double click, because there a single click is how a cell is selected without editing it. The second of those taps was worse than useless: `spreadsheet.js` clears the pin when what is clicked is already pinned, so tapping a cell twice with a pause between dropped the selection. It now clears the pin only in a sheet that is not being edited, where that gesture is the only way to put a raised cell back. Checked with `test/browser/sheet` - 115 checks over the five pages, none failing, with the tap path driven through a `matchMedia` that answers as a phone does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FJJdfqpnVCKBNHXjAVxSou
The editor opens over a `td`, so a second click there must not drop the pin it reads. A row or column header opens none, and clicking it again is how a reader puts it back, so the guard now asks for a `td`. The sheet checks drive the tap path: `editing.html` answers `(pointer: coarse)` the way a phone does, and checks what one click does on a cell, on a locked cell and on a header. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0149gFxhkvKTBQidz6brU8Vt
andiwand
force-pushed
the
feat/sheet-tap-to-edit
branch
from
September 20, 2026 09:33
4714d6c to
4e555a0
Compare
andiwand
added a commit
that referenced
this pull request
Sep 20, 2026
The pointer decides whether a click opens a cell's editor, and it is a guess: an android WebView reports `(pointer: coarse)` as false on an emulator, so the tap-to-edit of #908 did not happen there at all. `odr.editing.setSheetOptions({editOnClick})` lets the viewer state it, as `odr.annotation.setOptions` states the marking gestures. Unstated, the pointer answers as before. Checked with `test/browser/sheet` - 77 checks on the editing page, none failing, seven of them new. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FJJdfqpnVCKBNHXjAVxSou
andiwand
added a commit
that referenced
this pull request
Sep 20, 2026
…g as off
`setSheetOptions({editOnClick: undefined})` set the key, so `!== null` took it
as a stated no and a tap opened nothing. `!= null` reads both null and
undefined as unstated, which is what a host passing a value it does not have
means.
The design doc said a double click is what opens the editor, which #908 and
this one no longer make true.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0149gFxhkvKTBQidz6brU8Vt
andiwand
added a commit
that referenced
this pull request
Sep 20, 2026
* feat(html): the viewer states whether a click opens a sheet cell The pointer decides whether a click opens a cell's editor, and it is a guess: an android WebView reports `(pointer: coarse)` as false on an emulator, so the tap-to-edit of #908 did not happen there at all. `odr.editing.setSheetOptions({editOnClick})` lets the viewer state it, as `odr.annotation.setOptions` states the marking gestures. Unstated, the pointer answers as before. Checked with `test/browser/sheet` - 77 checks on the editing page, none failing, seven of them new. * fix(html): an unset `editOnClick` asks the pointer rather than reading as off `setSheetOptions({editOnClick: undefined})` set the key, so `!== null` took it as a stated no and a tap opened nothing. `!= null` reads both null and undefined as unstated, which is what a host passing a value it does not have means. The design doc said a double click is what opens the editor, which #908 and this one no longer make true. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
Reported from the Android app: editing a spreadsheet takes two taps per cell, and tapping a cell twice with a pause between deselects it.
Both come from the same place.
Opening a cell took a double click. A phone gives up two taps for one double click and reports the first as a tap of its own. The reader is already in the mode that edits, so on a coarse pointer the first tap now opens the editor. A fine pointer keeps the double click: there a single click is how a cell is selected without editing it.
The second tap dropped the selection.
spreadsheet.jsclears the pin when what is clicked is already pinned, andevent.detailonly covers the second click of a real double click - a tap, a pause, a tap is two clicks ofdetail: 1. The pin is now cleared only in a sheet that is not being edited, where that gesture is the only way to put a raised cell back.Checked
test/browser/sheet, all five pages: 14 + 22 + 8 + 61 + 10 = 115 checks, none failing. The desktop path is unchanged, and the tap path was driven through amatchMediathat answers as a phone does - one tap opens the editor over the cell's text, and a second click on a pinned cell keeps the pin while editing and still clears it while reading.