Recognize .bmp, .tiff, .tif, and .ico as supported image files#9395
Open
anshul-garg27 wants to merge 1 commit intowarpdotdev:masterfrom
Open
Recognize .bmp, .tiff, .tif, and .ico as supported image files#9395anshul-garg27 wants to merge 1 commit intowarpdotdev:masterfrom
anshul-garg27 wants to merge 1 commit intowarpdotdev:masterfrom
Conversation
Contributor
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I approved this pull request. No matching stakeholder was found for the changed files, so no human reviewers were requested. Comment Powered by Oz |
![oz-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Overview
This PR adds bmp, tiff, tif, and ico to the supported image extension check so binary image links can route to the system viewer, and adds regression coverage for the full supported image list plus case-insensitive extensions.
Concerns
- No blocking correctness, security, or maintainability concerns found in the changed lines.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
captainsafia
added
the
external-contributor
Warp Dev Github Integration
anshul-garg27
force-pushed
the
fix/sync-image-file-extensions
branch
from
39f202e to
720f90e
Compare
Contributor
Author
|
Rebased onto current The merge conflict in Fresh CI is now running. |
Contributor
Author
|
Update — also confirmed locally with Command: |
zachbai
pushed a commit
that referenced
this pull request
May 1, 2026
## Description Follow-up to #9395 in a different file. While auditing image-extension lists across the repo I found a third copy in `is_supported_blocklist_image_source` (`app/src/ai/blocklist/block/view_impl/common.rs`) that suffers from the exact same drift: it only matches `jpg | jpeg | png | gif | webp | svg`, missing `.bmp`, `.tiff` / `.tif`, and `.ico`. So inline references to local `.bmp` / `.tiff` / `.ico` images in agent block output fail the support check and don't render as the inline image — they silently fall back to plain text — even though the same files do route to the system viewer once #9395 lands. ```diff - "jpg" | "jpeg" | "png" | "gif" | "webp" | "svg" + "jpg" | "jpeg" | "png" | "gif" | "bmp" | "tiff" | "tif" | "webp" | "ico" | "svg" ``` The full picture, for context: | Location | What it does | Pre-fix | |---|---|---| | `crates/warp_util/src/file_type.rs` (`is_binary_file`) | Canonical binary-file extension list | 9 image formats | | `app/src/util/openable_file_type.rs` (`is_supported_image_file`) | Routes click-to-open to `FileTarget::SystemGeneric` | 6 formats — fixed in #9395 | | **This PR** — `app/src/ai/blocklist/block/view_impl/common.rs` (`is_supported_blocklist_image_source`) | Gates inline rendering of agent block image references | 6 formats | | `crates/warpui_core/src/platform/file_picker.rs` (`FileType::Image`) | Theme-creator file-picker filter | 3 formats — left for a separate PR; the right "what should be selectable as a theme background" set is more subjective | ## Testing - Added `is_supported_blocklist_image_source_covers_common_local_formats` in `common_tests.rs`. Asserts every supported extension passes (10 cases), case-insensitivity (`PHOTO.PNG`, `scan.TIFF`), and that HTTP / HTTPS sources and non-image extensions still return false. Fails on master for the four new extensions, passes after the change. - `cargo fmt -p warp -- --check` passes locally. - Couldn't run `cargo nextest` locally because the Metal toolchain isn't installed (same caveat as #9277, #9345, #9346, #9395) — relying on CI for the full clippy / nextest pass. ## Related - #9395 — same fix for `is_supported_image_file` (file-open routing path). ## Changelog Entries for Stable CHANGELOG-BUG-FIX: Inline `.bmp`, `.tiff` / `.tif`, and `.ico` images in agent block output now render correctly instead of falling back to plain text. Co-authored-by: anshul-garg27 <[email protected]>
zerx-lab
pushed a commit
to zerx-lab/warp
that referenced
this pull request
May 3, 2026
## Description Follow-up to warpdotdev#9395 in a different file. While auditing image-extension lists across the repo I found a third copy in `is_supported_blocklist_image_source` (`app/src/ai/blocklist/block/view_impl/common.rs`) that suffers from the exact same drift: it only matches `jpg | jpeg | png | gif | webp | svg`, missing `.bmp`, `.tiff` / `.tif`, and `.ico`. So inline references to local `.bmp` / `.tiff` / `.ico` images in agent block output fail the support check and don't render as the inline image — they silently fall back to plain text — even though the same files do route to the system viewer once warpdotdev#9395 lands. ```diff - "jpg" | "jpeg" | "png" | "gif" | "webp" | "svg" + "jpg" | "jpeg" | "png" | "gif" | "bmp" | "tiff" | "tif" | "webp" | "ico" | "svg" ``` The full picture, for context: | Location | What it does | Pre-fix | |---|---|---| | `crates/warp_util/src/file_type.rs` (`is_binary_file`) | Canonical binary-file extension list | 9 image formats | | `app/src/util/openable_file_type.rs` (`is_supported_image_file`) | Routes click-to-open to `FileTarget::SystemGeneric` | 6 formats — fixed in warpdotdev#9395 | | **This PR** — `app/src/ai/blocklist/block/view_impl/common.rs` (`is_supported_blocklist_image_source`) | Gates inline rendering of agent block image references | 6 formats | | `crates/warpui_core/src/platform/file_picker.rs` (`FileType::Image`) | Theme-creator file-picker filter | 3 formats — left for a separate PR; the right "what should be selectable as a theme background" set is more subjective | ## Testing - Added `is_supported_blocklist_image_source_covers_common_local_formats` in `common_tests.rs`. Asserts every supported extension passes (10 cases), case-insensitivity (`PHOTO.PNG`, `scan.TIFF`), and that HTTP / HTTPS sources and non-image extensions still return false. Fails on master for the four new extensions, passes after the change. - `cargo fmt -p warp -- --check` passes locally. - Couldn't run `cargo nextest` locally because the Metal toolchain isn't installed (same caveat as warpdotdev#9277, warpdotdev#9345, warpdotdev#9346, warpdotdev#9395) — relying on CI for the full clippy / nextest pass. ## Related - warpdotdev#9395 — same fix for `is_supported_image_file` (file-open routing path). ## Changelog Entries for Stable CHANGELOG-BUG-FIX: Inline `.bmp`, `.tiff` / `.tif`, and `.ico` images in agent block output now render correctly instead of falling back to plain text. Co-authored-by: anshul-garg27 <[email protected]>
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
2 participants
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.
Description
is_supported_image_fileinapp/src/util/openable_file_type.rsandis_binary_fileincrates/warp_util/src/file_type.rscarry overlapping image-extension lists, but they're not in sync:is_binary_fileis_supported_image_filejpg/jpeg/png/gif/webpsvgbmptiff/tificoThe four bottom rows are the bug. Their flow today:
is_file_openable_in_warp(file.bmp)→ returnsNonebecauseis_binary_filematches.ai/blocklist/block.rs:274,notebooks/link.rs:355,ai/ai_document_view.rs:919) then checkis_supported_image_fileto decide whether to route toFileTarget::SystemGeneric(i.e. open in Preview / system default).false, so the file falls through with no working target — clicking a.bmp/.tiff/.icolink from a notebook or AI block has no effect.This change adds the four missing extensions to
is_supported_image_fileso they route to the system viewer the way.pngand friends already do.svgstays inis_supported_image_fileonly — it's text/XML and correctly excluded fromis_binary_file.Testing
test_is_supported_image_file_covers_common_formatsin the existing inline#[cfg(test)] mod testsblock. It covers all 10 supported extensions, asserts case-insensitivity (PNG,TIFF), and confirms non-image extensions still return false. Fails on master for the four new extensions; passes after the change.cargo fmt -p warp -- --checkpasses locally.cargo nextestlocally because the Metal toolchain isn't installed (same caveat as Expand~inwarp://action/new_tab?path=URLs #9277, Recognize .command files as shell scripts #9345, Also recognize .h++ as a C++ header extension #9346) — relying on CI for the full clippy / nextest pass.Changelog Entries for Stable
CHANGELOG-BUG-FIX:
.bmp,.tiff/.tif, and.icofiles now open in the system default viewer when clicked from notebooks and AI blocks, matching the behavior already in place for.png,.jpg, etc.