Skip to content

feat(html): a tap opens a sheet cell's editor on a touch screen - #908

Merged
andiwand merged 2 commits into
mainfrom
feat/sheet-tap-to-edit
Sep 20, 2026
Merged

andiwand merged 2 commits into
mainfrom
feat/sheet-tap-to-edit

Conversation

@andiwand

@andiwand andiwand commented Sep 20, 2026 •

Copy link
Copy Markdown
Member

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.js clears the pin when what is clicked is already pinned, and event.detail only covers the second click of a real double click - a tap, a pause, a tap is two clicks of detail: 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 a matchMedia that 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.

andiwand added a commit that referenced this pull request Sep 20, 2026
Not for merge: this branch only exists so CI assembles an AAR carrying PR #907 and PR #908 together, for a device test.
andiwand and others added 2 commits September 20, 2026 11:29
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
andiwand force-pushed the feat/sheet-tap-to-edit branch from 4714d6c to 4e555a0 Compare September 20, 2026 09:33
@andiwand
andiwand merged commit 6d1d47b into main Sep 20, 2026
25 checks passed
@andiwand
andiwand deleted the feat/sheet-tap-to-edit branch September 20, 2026 09:34
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant