Route the remote's Play and Pause keys through the same pause and resume as OK

[Kisnov]

Pull Request

Summary

The remote's dedicated Play and Pause keys open-coded their own avplayPlay/avplayPause instead of sharing handlePlayPause's body, so the bookkeeping that hangs off a pause applied to some ways in and not others. Most visibly, Unpause Rewind was skipped when resuming with Play but applied when resuming with OK — the same setting rewound or did not depending on which button was pressed.

Follow-up to #436, which surfaced this. Independent of it — branched from main, no overlap.

Related Issues

• Related to Toggle playback when OK is pressed on the progress bar #436

Type of Change

• Bug fix
• Refactor

Changes Made

• Pulled the two halves of handlePlayPause out as pausePlayback and resumePlayback. handlePlayPause becomes the toggle that dispatches on AVPlay state; the one-way keys call the halves directly, so Play still cannot pause and Pause cannot resume — that asymmetry is why they were not simply calling the toggle already.
• SyncPlay semantics deliberately preserved: the group guards moved into the halves (where KEYS.PLAY/KEYS.PAUSE already had them), and handlePlayPause keeps its own so a state that is neither PLAYING nor PAUSED/READY still sends a play request, exactly as before.
• webOS had the same split — its Play key called video.play() directly and skipped the rewind. The rest of its bookkeeping rides the media element's own play/pause events, so only the rewind needed moving, hence the much smaller diff there.

What each entry point did before, and now does uniformly:

Resume via	unpauseRewind	reportProgress	healthMonitor.setPaused
OK / play-pause button	yes	yes	yes
KEYS.PLAY_PAUSE (10252)	yes	yes	yes
KEYS.PLAY (415)	no → yes	no → yes	no → yes
KEYS.PAUSE (19)	—	no → yes	no → yes

On the two secondary columns, for honesty about severity: reportProgress was real but minor (the 10 s poll reported the state anyway, just late). healthMonitor.setPaused was inert — Tizen's handleUnhealthy only logs, and webOS's guards on video.paused. Fixed for correctness, not because either misbehaved.

One new behaviour worth noting: pressing Play from READY now applies Unpause Rewind and reports progress, where before it just played. Consistent with the OK button, but new for that key.

Platform

• Both / Shared code

Testing

• Tested on emulator
• Tested on physical device
• Manual testing completed
• Not tested (explain why): no panel run of this branch. A .wgt was built from it but not installed. enact lint is clean on both files and CI Build [Playback] When playback speed is applied there is no sound #290 passed all four platform builds and the test suite.

Worth exercising with Unpause Rewind set to a non-zero value — with it Off every path looks identical and there is nothing to see.

Not exercised: SyncPlay. The guards are unchanged, but this is the part most worth a maintainer's eye.

Test Steps

1. Set Unpause Rewind to a non-zero value.
2. Pause with OK, resume with the Play key → should now rewind (previously did not).
3. Pause with the Pause key, resume with OK → should rewind.
4. Press Play while already playing → must not pause.
5. Press Pause while already paused → must not resume.
6. Set Unpause Rewind to Off → none of the above should move the position.

Screenshots (if applicable)

Not applicable — no visual change; this is key handling and playback bookkeeping.

Checklist

• Code builds successfully — CI Build [Playback] When playback speed is applied there is no sound #290, all four platform builds
• Code follows project style and conventions
• No unnecessary commented-out code
• No new warnings introduced — enact lint clean

🤖 Generated with Claude Code

[github-actions]

✅ Build Successful

All platform builds and the test suite passed. You can download the artifacts below.

Platform	Status	Artifact
webOS	✅ Passed	Moonfin_webOS_*.ipk
Tizen Regular	✅ Passed	Moonfin_Tizen_Regular_*.wgt
Tizen Oblong	✅ Passed	Moonfin_Tizen_Oblong_*.wgt
Tizen Legacy	✅ Passed	Moonfin_Tizen_Legacy_*.wgt

Property	Value
Commit	1771349
Workflow run	Build #290