sender can't open a picture sent directly to the contact's device #47

New issue

Closed

opened 2026-10-22 02:08:10 +00:00 by bmt · 2 comments

bmt commented

2026-10-22 02:08:10 +00:00

Member

steps:

send a picture to a contact
wait until it is delivered
open the picture in your own chat

expected: the sender can open and copy their own sent picture

actual: "couldn't fetch it", the picture can't be opened or copied

after sending a picture/video to a contact, the sender can't open it, though it is delivered and its preview shows in the chat. the viewer shows "couldn't fetch it" and offers only Retry, which doesn't help. copying it copies only the file name. steps: 1. send a picture to a contact 2. wait until it is delivered 3. open the picture in your own chat expected: the sender can open and copy their own sent picture actual: "couldn't fetch it", the picture can't be opened or copied

05-05-17.mp4

4.2 MiB

bmt added the

bug

label

2026-10-22 02:08:10 +00:00

ann referenced this issue from a commit

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

The sender opens and copies their own picture or video sent directly to the contact's device (#47, bmt: "after sending a picture/video to a contact, the sender can't open it, though it is delivered and its preview shows in the chat. the viewer shows "couldn't fetch it" and offers only Retry, which doesn't help. copying it copies only the file name").

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 commented

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

Owner

A picture or video you sent directly to the contact's device now opens and copies on your side too; "Copy image" is on the message menu.

Fixed on develop in 3a0eaf60, 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.

A picture or video you sent directly to the contact's device now opens and copies on your side too; "Copy image" is on the message menu. Fixed on `develop` in 3a0eaf60, 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.

bmt commented

2026-10-27 01:40:13 +00:00

Author

Member

partly fixed:
a picture sent directly can’t be opened by the sender for the first 1–2 minutes then it opens, although the transfer itself finishes in a few seconds

expected: the sender can open the picture right after sending

partly fixed: a picture sent directly can’t be opened by the sender for the first 1–2 minutes then it opens, although the transfer itself finishes in a few seconds expected: the sender can open the picture right after sending

ann referenced this issue from a commit

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

A picture or file sent directly (Jingle) opens on the sender's side as soon as the send is done (#47, bmt 2026-10-27: "a picture sent directly can't be opened by the sender for the first 1-2 minutes then it opens, although the transfer itself finishes in a few seconds"): libtacky stored the row's p2p: url when the peer confirmed the file but told the page only `message <Status> pending`, which carries no attachment, so the page kept the row as it was while sending, with no url, and the viewer had nothing to read until something else redrew the row; libtacky develop cd823309 now sends the row again as `<Edited>` first, as it does for an upload, and the page's existing path (#fetchOwnLanded, notePath) reads the picture from the path it was sent from. Submodule libtacky 00e41b89 -> cd823309 (with ccb22b49's conn bound_jid and the status module, unused here), ui/src/protocol/generated/api.ts regenerated. Test: direct-transfers.test.ts gains a store case, an uploading direct row patched by <Edited> under its p2p: url, read from its path at once with no pathless read (fails without the <Edited>). CHANGELOG Unreleased: Fixes #47. make check STRICT=1 clean (2031 keys), make test-ui 366 files, 3979 passed, 8 skipped, make test-shell ok.

ann closed this issue

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