Skip to content

Replace image-only attachment with general file attachment support using paperclip icon #5532

@MuriloFP

Description

@MuriloFP

What specific problem does this solve?

What specific problem does this solve?

Currently, Roo's chat interface only supports attaching images through a camera icon button. This limitation significantly impacts users who need to share other file types with the AI for analysis or context.

Who is affected: All Roo users who work with non-image files (code files, documents, data files, configuration files, etc.)

When this happens: Users need to share files like:

  • Configuration files (XML, JSON, YAML)
  • Documents (TXT, MD, PDF)
  • Data files (CSV, TSV)
  • Code files from outside the workspace
  • Log files for debugging

Current behavior:

  • Only image files (PNG, JPG, JPEG, WEBP) can be attached
  • Camera icon suggests only photo/image functionality
  • Users must copy-paste file contents manually for non-image files

Expected behavior:

  • Support attaching any file type
  • Use a paperclip icon to indicate general file attachment capability
  • Handle both images (as data URLs) and other files (as file paths/content)

Impact:

  • Time wasted manually copying file contents
  • Inability to share binary files
  • Confusion from camera icon when users want to attach documents
  • Reduced productivity when working with multiple file types

Additional context (optional)

Additional context

The reference implementation in Cline shows this working well with a file dialog that dynamically adjusts filters based on model capabilities.

Roo Code Task Links (Optional)

No response

Request checklist

  • I've searched existing Issues and Discussions for duplicates
  • This describes a specific problem with clear impact and context

Interested in implementing this?

  • Yes, I'd like to help implement this feature

Implementation requirements

  • I understand this needs approval before implementation begins

How should this be solved? (REQUIRED if contributing, optional otherwise)

🛠️ Contributing & Technical Analysis

I'm interested in implementing this feature
I understand this needs approval before implementation begins

How should this be solved?

Replace the current image-only attachment system with a general file attachment system that supports all file types while maintaining backward compatibility for image handling.

What will change:

  • Replace camera icon (codicon-device-camera) with paperclip icon (codicon-clippy)
  • Update button tooltip from image-specific to "Attach files"
  • Modify file selection dialog to accept all file types
  • Process images as data URLs (existing behavior)
  • Handle non-image files appropriately (content reading or path reference)

User interaction:

  • Click paperclip icon to open file dialog
  • Select any file type (images, documents, code files, etc.)
  • Images display as thumbnails in chat (existing behavior)
  • Other files show as attachment indicators with filename
  • AI receives appropriate file content/reference

How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)

Given I am in the Roo chat interface
When I click the attachment button
Then I see a file dialog that accepts all file types
And the button shows a paperclip icon instead of camera icon

Given I select an image file
When I attach it to my message
Then it displays as a thumbnail in the chat
And the AI receives it as a data URL (existing behavior)

Given I select a non-image file (e.g., .json, .txt, .xml)
When I attach it to my message
Then it shows as an attachment with the filename
And the AI receives the file content or path appropriately
But binary files that can't be read as text show an appropriate message

Given I have a model that doesn't support images
When I open the file dialog
Then I can still select any file type
But image files are processed as text descriptions or paths

Technical considerations (REQUIRED if contributing, optional otherwise)

Technical Considerations

Implementation approach:

  • Key files to modify:

    • webview-ui/src/components/chat/ChatTextArea.tsx (update icon and handler)
    • src/integrations/misc/process-images.ts (rename/refactor to process-files.ts)
    • src/core/webview/webviewMessageHandler.ts (update message handling)
    • Translation files for updated tooltips/messages
  • Current architecture:

    • Button in ChatTextArea triggers onSelectImages
    • Message sent to webview handler
    • selectImages() opens dialog with image-only filters
    • Images processed to data URLs
  • Integration points:

    • Reuse existing image processing for image files
    • Add new file content reading for text files
    • Update message types to handle file attachments
  • Similar patterns in codebase:

    • Cline's implementation in reference/Cline/src/integrations/misc/process-files.ts
    • Existing image handling can be extended rather than replaced

Performance implications:

  • Large files may need size limits or streaming
  • Binary file detection needed to avoid reading non-text files
  • Consider lazy loading for file contents

Compatibility concerns:

  • Maintain backward compatibility with existing image handling
  • Ensure models without image support still work
  • Handle file reading errors gracefully

Trade-offs and risks (REQUIRED if contributing, optional otherwise)

Trade-offs and Risks

Alternatives considered:

  • Keep separate buttons for images and files: Rejected - more complex UI, confusing for users
  • Only support text files: Rejected - too limiting, users need various file types
  • Use drag-and-drop only: Rejected - not discoverable, accessibility concerns

Potential risks:

  • Large file handling: Mitigation - implement file size limits with clear user messaging
  • Binary file issues: Mitigation - detect and handle binary files appropriately
  • Security concerns: Mitigation - maintain existing file access restrictions

Breaking changes:

  • None expected - extending functionality rather than replacing
  • Existing image attachment behavior preserved
  • Message format extensions should be backward compatible

Metadata

Metadata

Assignees

Labels

Issue - In ProgressSomeone is actively working on this. Should link to a PR soon.enhancementNew feature or requestproposal

Type

No type

Projects

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions