Repository navigation
Conversation
…eflow#1063) A failure while reading or decoding a cached file was never delivered to the image stream. Report it, evict the image, remove the broken cache entry and close the streams. Also close the streams when every decode finished before the download completed.
…aseflow#1065) * test: reproduce retained decoded animation frames * fix: dispose queued animation frame with image completer * fix: detach animation frame before notifying listeners * fix: release codecs through framework disposal lifecycle * fix: preserve refresh selection and dispose late codecs * fix: discard superseded codecs and preserve refresh frame counts * docs: clarify pending refresh selection at cycle boundaries * fix: activate completed-animation refreshes and preserve frame timing * docs: set 4.0.6 release date to October 29
cached_network_image 4.0.6
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
|
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
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.
✨ What kind of change does this PR introduce? (Bug fix, feature, docs update...)
A fork sync. It merges upstream
Baseflow/flutter_cached_network_imagetagv4.0.6(5387cfa, which is also upstreammain) into the fork'smain. The merge is clean, with no conflicts, and all three Stift patches are kept.Upstream's release commits are in the range, so the packages move to the versions upstream published:
cached_network_image4.0.6,cached_network_image_web2.0.4.cached_network_image_platform_interfacestays at 5.0.3. EveryCHANGELOG.mdandversion:line in the diff is upstream's. This PR adds none of its own, which is why it touches two packages instead of one.The fork is at upstream v4.0.5 plus Stift's web patches. It is missing two upstream fixes:
a2a555bfix(web): report cached file read and decode failures onHttpGet(fix(web): report cached file read and decode failures on HttpGet Baseflow/flutter_cached_network_image#1063).5387cfafix: dispose the queued animation frame when the image completer is disposed (fix: dispose queued animation frame when image completer is disposed Baseflow/flutter_cached_network_image#1065).🆕 What is the new behavior (if this is a feature change)?
Web (
HttpGet, Stift's default),a2a555b:removeFile(cacheKey ?? url)), andevictImageis called, so a retry downloads again._decodeBytesis the decode callback for bothloadBufferAsyncandloadImageAsync.decodeWithImageBitmapcatches its own errors and falls back to the engine. Engine errors are the ones upstream now reports, at most once (guarded bysettling/finished).All platforms,
5387cfa: a frame that resolves afterMultiImageStreamCompleteris disposed, or after its codec is swapped, is now disposed instead of leaked. Combined with Stift's_ImageBitmapCodec.dispose, which frees only images never handed out, each frame is freed exactly once.ad5dbdbfeat(web): defaultImageRenderMethodForWebtoHttpGetb485cd2fix(web): decode images via ImageBitmap so they stop painting black on Firefox9b7114estyle(web): format the ImageBitmap decode patch filesAfter the merge, the fork's diff against
v4.0.6is exactly those patches: 8 files, +263/−11.💥 Does this PR introduce a breaking change?
No.
🐛 Recommendations for testing
What ran in the fork:
flutter analyzeis clean in all three packages.flutter test: platform interface 1/1, app-facing 75/75, web 19/19 (--platform chrome, Chromium).What ran against the Stift app: the three packages were pointed at this branch via a local
path:(not committed), on appmain5a1da20, Flutter 3.47.8.mainflutter analyze(E/W/I)flutter testflutter build web --releasemain.dart.js23,718,926 BThe app needs no code changes. It tracks this fork's
main, so the app's next lock refresh picks this up.What wasn't covered: the ImageBitmap path itself. On Chrome the engine already decodes with WebCodecs, so the web tests only exercise the engine fallback. Please check by hand on Firefox and Safari (Flutter web,
HttpGet):httpHeadersload.Known upstream behaviour, not introduced by Stift: if a stale cached file decodes but the fresh one that follows is broken, the stream finishes without error and the broken file stays cached until the next load fails once.
A self-review against the Stift app's
.claude/skills/deps-update/review.mdfound architecture, security, performance and functionality all OK, with no blockers. Caller headers are still sent only togetFileStream, and the newremoveFiledeletes only that image's own entry.📝 Links to relevant issues/docs
v4.0.6andweb-v2.0.4changelog entries in the diff.🤔 Checklist before submitting
Generated by Claude Code