The strip says frozen when nobody swiped #22

New issue

Closed

opened 2026-08-10 14:23:08 +00:00 by aiko · 1 comment

aiko commented

2026-08-10 14:23:08 +00:00

Owner

Parent

What is wrong

From a real episode: "it almost always says frozen at 0:00."

+0:00 is the tell. The strip froze on the panel that is already live, which means the settle it reacted to was its own auto-scroll, not a reader's swipe. #18 identified this race and judged the window small: if the Playhead crosses into the next Cue between an auto-scroll starting and its scrollend, the settle reads as a reader move. It is not small. It is the common case.

The consequence is worse than a wrong label. A spurious freeze stops the strip following the show, so the reader has to keep pressing a control to undo something they never did — and with follow mode on it also fires a seek backwards, writing to a session other people are watching.

#18 rejected the obvious fix — tracking the app's own scroll target separately from panelIndex — as duplicating what panelIndex already means. That judgement was made against a rare race. Reconsider it against a constant one, or find a better discriminator: what matters is that the strip can tell its own scrolling from the reader's.

Do not fix this by suppressing the label. A strip that has stopped following and no longer says so is the failure ADR 0007 exists to prevent.

Acceptance criteria

The strip does not enter the frozen state from its own auto-scroll, including when the Playhead crosses a Cue boundary mid-scroll
A real swipe still freezes, and still reports an honest offset
With follow mode on, no seek is issued for a settle the reader did not cause
An offset of +0:00 while frozen is either impossible or means something true
The discriminator between the app's scrolling and the reader's is covered by tests, including the boundary-crossing case that produced this bug

Blocked by

## Parent #1 ## What is wrong From a real episode: *"it almost always says frozen at 0:00."* `+0:00` is the tell. The strip froze on the panel that is already live, which means the settle it reacted to was **its own auto-scroll**, not a reader's swipe. #18 identified this race and judged the window small: if the Playhead crosses into the next Cue between an auto-scroll starting and its `scrollend`, the settle reads as a reader move. It is not small. It is the common case. The consequence is worse than a wrong label. A spurious freeze stops the strip following the show, so the reader has to keep pressing a control to undo something they never did — and with follow mode on it also fires a seek backwards, writing to a session other people are watching. #18 rejected the obvious fix — tracking the app's own scroll target separately from `panelIndex` — as duplicating what `panelIndex` already means. That judgement was made against a rare race. Reconsider it against a constant one, or find a better discriminator: what matters is that the strip can tell its own scrolling from the reader's. Do not fix this by suppressing the label. A strip that has stopped following and no longer says so is the failure ADR 0007 exists to prevent. ## Acceptance criteria - [ ] The strip does not enter the frozen state from its own auto-scroll, including when the Playhead crosses a Cue boundary mid-scroll - [ ] A real swipe still freezes, and still reports an honest offset - [ ] With follow mode on, no seek is issued for a settle the reader did not cause - [ ] An offset of `+0:00` while frozen is either impossible or means something true - [ ] The discriminator between the app's scrolling and the reader's is covered by tests, including the boundary-crossing case that produced this bug ## Blocked by - #15 - #18

aiko added the

ready-for-agent

label

2026-08-10 14:23:08 +00:00

aiko referenced this issue from a commit

2026-08-10 16:20:44 +00:00

fix(web): the strip does not freeze on its own auto-scroll

aiko referenced this issue from a commit

2026-08-10 16:20:44 +00:00

merge: tell the strip's own scrolling from the reader's (#22)

aiko commented

2026-08-10 16:21:28 +00:00

Author

Owner

This was generated by AI during triage.

Merged to main in af73452. Suites at merge: 79 C#, 335 phone.

The strip said frozen when nobody swiped, almost always, at +0:00.

The cause was a false premise in a doc comment: panelIndex was described as the panel on screen, when it is the panel that should be on screen. With smooth scrolling the strip is still travelling, so crossing a Cue boundary mid-scroll made the app's own scroll read as a reader's swipe — freezing, and with follow mode on, seeking backwards with no gesture behind it.

The strip now records what it told itself to do. The scroll helper was folded so there is no way to scroll without recording it.

> *This was generated by AI during triage.* Merged to `main` in af73452. Suites at merge: 79 C#, 335 phone. The strip said frozen when nobody swiped, almost always, at `+0:00`. The cause was a false premise in a doc comment: `panelIndex` was described as the panel on screen, when it is the panel that *should* be on screen. With smooth scrolling the strip is still travelling, so crossing a Cue boundary mid-scroll made the app's own scroll read as a reader's swipe — freezing, and with follow mode on, seeking backwards with no gesture behind it. The strip now records what it told itself to do. The scroll helper was folded so there is no way to scroll without recording it.

aiko closed this issue

2026-08-10 16:21:28 +00:00

aiko referenced this issue

2026-08-10 16:53:41 +00:00

Make the phone say what it thinks is happening #24

aiko referenced this issue

2026-08-11 21:41:45 +00:00

A swipe onto a panel the app was already heading for is still a swipe #26

aiko referenced this issue from a commit

2026-08-11 21:54:45 +00:00

fix(web): ask the hand whose swipe it was, not the panel

aiko referenced this issue