fix(iOS): load leading images from plain file paths on iOS list items - #73
Open
SRWieZ wants to merge 1 commit into
Open
fix(iOS): load leading images from plain file paths on iOS list items#73SRWieZ wants to merge 1 commit into
SRWieZ wants to merge 1 commit into
Conversation
A list row's leading image and avatar both resolve their source through AsyncImage alone. `URL(string:)` on a bare absolute path yields a URL with no scheme, URLSession has nothing to fetch, and the row keeps its placeholder forever. file:// and http(s) sources were unaffected. Plain absolute paths are what the PHP side hands over — public_path(), storage_path(), and the paths returned by the camera and file pickers — and the <image> element already decodes them via UIImage(contentsOfFile:). The same string therefore rendered in <image> and silently failed in <list-item leadingImage="…">. Decode local sources directly in both leading slots and keep AsyncImage for remote URLs. The local-source check moves into NativeUILocalImage so the two renderers cannot drift on what counts as local.
SRWieZ
changed the title
SRWieZ
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
Give a list item a leading image that lives on the device:
On Android you get the image. On iOS you get a grey placeholder, forever.
file://andhttps://sources arefine — it's the plain path that dead-ends.
That's the shape most PHP sources have:
public_path(),storage_path(), and the paths the camera and filepickers hand back.
<native:image>already accepts them, so today the same string renders in one element andsilently fails in the other.
Why
Both leading slots resolve their source through
AsyncImagealone:URL(string: "/var/…/photo.png")has no scheme, so URLSession has nothing to fetch and the placeholder nevergoes away.
The fix
Decode local sources with
UIImage(contentsOfFile:)— exactly whatNativeUIImageRendereralready does — andkeep
AsyncImagefor remote URLs. Applied to both theimageandavatarslots, since an avatar is just aslikely to be a file the app just saved.
The "is this local?" check moves into a shared
NativeUILocalImage, so the two renderers can't drift on theanswer.
iOS only — Android's Coil takes a path as-is. No PHP or wire changes, and nothing that renders today changes:
only sources that showed a placeholder start showing an image.
Before / after (iPhone 17 simulator, iOS 26, same Blade)