image viewer: arrow keys don’t work until you click inside #29

New issue

Closed

opened 2026-10-21 20:21:19 +00:00 by tlasol · 2 comments

tlasol commented

2026-10-21 20:21:19 +00:00

Member

expected:
arrows work right after the viewer opens

actual:
arrows do nothing until the first click inside the viewer

description when an image is opened in the viewer, left/right arrows don’t switch between images in the chat. they start working only after clicking on the image or somewhere in the viewer. looks like the viewer doesn’t get keyboard focus when it opens expected: arrows work right after the viewer opens actual: arrows do nothing until the first click inside the viewer

tlasol added the

macos

ui/ux

labels

2026-10-21 20:21:19 +00:00

ann referenced this issue from a commit

2026-10-23 21:50:17 +00:00

The media viewer: arrow keys from the start, a click that zooms with zoom buttons in the header, its own close button on a backdrop the chat shows through, and no stickers among the photos (#29, #30, #31, #37). No change of its own: a record of a change that the shared worktree index swept into two other coders' commits while it was being staged -- the code, tests and smoke checks into ac1681e7 (stickers) and the catalogue strings (Close (Esc), Zoom in, Zoom out, Fit to window, in en.json and the six catalogues) into 08320a28 (room avatars).

ann referenced this issue from a commit

2026-10-23 21:50:17 +00:00

0.7.1-dev, a test build on libtacky develop b5fd9316 (the user, 2026-10-24: "mark it 0.7.1-dev, release gms apk, flatpak and windows standalone for now as its test"): the version in ui/package.json and its lock, src-tauri/tauri.conf.json, Cargo.toml and Cargo.lock, the CHANGELOG's 0.7.1-dev entry naming every forge issue it answers (#33, #47, #39, #38, #37, #44, #45, #48, #36, #32, #43, #29, #30, #31 fixed; #46 and #40 added), and the metainfo's development release, named 0.7.2~dev there because appstream sorts 0.7.1~dev below the 0.7.1 release (appstreamcli validate --no-net passes). The README's figures wait for the release. On the branch before the pin and this bump: make test-ui 2658 passed and 8 skipped, make check STRICT=1 clean, make test-shell 185 passed.

ann referenced this issue from a commit

2026-10-24 19:51:35 +00:00

The media viewer takes its keys whatever has the focus, and a chat under a media viewer is not on screen, so a message arriving there is notified (the user, 2026-10-24: "in image viewer keys shortcuts are not working: right/left, escape; also notifications are not working when viewing pictures and receiving messages in same chat (should work so chat should go 'unfocused')"). The keys used to follow the focus: the viewer's own listener when the stage had it, and otherwise a document listener in the bubble phase that stood aside for any text field and for a key some other listener had already taken, so with the caret left in or given back to the composer under the viewer Left and Right moved a hidden caret and Escape went to the composer, clearing a reply or a tray under the viewer; the 0.7 release the user also runs lacks even the #29 focus fix. The viewer now listens on the window in the capture phase while it is the top layer (no menu, dialog or sheet over it, not the shell's add-account sheet, not inert under the app lock), steps, zooms and closes on Escape as a step back before anything else hears the key, leaves Copy to a field with the caret and the keys of a path through the viewer to its own listener and the sheet, and moves the focus to its stage. For the notices, ChatScreen hides the open chat while a media viewer or the media browser lies over it (mediaOver, also used by the chat view), so libtacky alerts for it and reads none of it until the viewer closes and the chat, shown again, says how far down it is; Notifications lets a Notify for the chat under the viewer through though the window is in front, with the notice's sound, and drops the open chat's quieter pop meanwhile. Messages under the viewer stay unread and their notice up until the viewer closes. Tests: media-viewer.test.ts (keys from the body and from a field under the viewer, the field never hearing them, Escape closing, nothing taken under a sheet, the shell's sheet or an inert host), viewer-close-focus.test.ts (a picture opened from the feed, the caret put back in the composer, real Left, Right and Escape), chat-screen.test.ts (hidden under the viewer and the browser, no view sent meanwhile, shown again after) and notification-throttle.test.ts (the notice and its sound under the viewer and the browser, another chat still quiet, the pop back once it closes); all six fail without the change. Real input on the mock build through GTK events in WebKitGTK and CDP in Chromium stepped and closed before and after the change, so the user's exact path was not reproduced. make check STRICT=1 clean, make test-ui 2669 passed and 8 skipped.

ann commented

2026-10-24 22:08:43 +00:00

Owner

Fixed on develop in 64703a05 + 58bc4624, in the 0.7.1-dev test build (gms apk, Flatpak, Windows setup and portable zip) of 2026-10-24. Please reopen if it still misbehaves there.

The media viewer takes the arrow keys as soon as it opens, no click needed. Note: the 0.7 release never had this fix; 0.7.1-dev does, and develop now also takes Left, Right and Escape whatever has the focus, the message field under the viewer included. Fixed on `develop` in 64703a05 + 58bc4624, in the 0.7.1-dev test build (gms apk, Flatpak, Windows setup and portable zip) of 2026-10-24. Please reopen if it still misbehaves there.

ann commented

2026-10-27 05:35:08 +00:00

Owner

Closing: answered above and no reply since; reopen if needed.

ann closed this issue

2026-10-27 05:35:08 +00:00