HIGH: [Polish] Add support for inline image Markdown

[quinthar]

Problem:

NewDot has the ability to display inline image -- we send them all the time from Concierge. But there is no way for a user to send one.

Solution:

Add support for the Markdown image syntax, initially for publicly hosted images to start.

[quinthar]

@kidroca FYI

[kidroca]

I'm not able to self-assign myself to this issue, but this comment should allow anyone with access to assign me

In the meantime I'll review how we're currently handling MD parsing and how that integrates with the HTML renderer used in report action comments and then propose how we might update it to handle MD image syntax for publicly hosted images

[kidroca]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The problem is that NewDot currently lacks the functionality for users to send inline images, although it can display images sent from Concierge.

What is the root cause of that problem?

The root cause is that ExpensiMark does not support Markdown image syntax, which is essential for embedding images in user-generated content.

What changes do you think we should make in order to solve the problem?

To address the problem, we need to enhance the ExpensiMark library, which is responsible for processing comments in NewDot by converting them into HTML before they are sent to the backend. Specifically, the following updates are recommended for ExpensiMark to improve image handling:

1. Markdown Image Syntax to HTML Conversion Rule: Implement a rule within ExpensiMark to convert Markdown image syntax (![Alt text](URL)) to an HTML <img> tag. This rule ensures that users can embed images directly in their comments using Markdown, which the library will then automatically translate into HTML for rendering in the web interface.

2. HTML Image Tag to Markdown Conversion Rule: Add a rule for converting HTML <img> tags back to Markdown image syntax. This is important for maintaining consistency when editing comments that already contain images, allowing the original Markdown formatting to be preserved and edited by users.

3. Optional HTML Image Tag to Text Conversion Rule: Introduce an optional rule for converting HTML <img> tags into plain text descriptions of the images, utilizing the alt attribute.

What alternative solutions did you explore? (Optional)

N/A

[kidroca]

Status Update

I've initiated a pull request to introduce the feature of embedding public images using Markdown syntax, available at: PR #37566.

Upon enabling this functionality, we've encountered a couple of significant, unplanned issues:

1. Non-Unique URLs for Public Images: The feature allows the same public image to be embedded multiple times across comments, leading to non-unique source URLs. This complicates our existing logic for attachment comparison and carousel positioning.

2. Public Images Without File Extensions: Some public images do not have file extensions in their URLs, which disrupts our fullscreen attachment rendering logic. This results in fallback content being displayed instead of the intended image.

Secondary Issue:

• Markdown Syntax Translated into HTML Attributes: In the expensify-common PR, we've noted that Markdown syntax is being translated into HTML within attributes, such as alt tags for images. While this edge case isn't causing visible problems at the moment, it has the potential for unexpected behavior.

Proposed Solutions:

• For the first issue, I recommend dynamically generating identifiers for each embedded image using the format ${reportActionID}-${source}-${attachmentIndex}, allowing for unique identification even when the same image is used multiple times.

• To address the second issue, I propose maintaining the current extension-based identification logic but adding a fallback mechanism. If an image lacks an extension, we should attempt to render it as an image first. Should this fail, we can then resort to displaying fallback content. Alternatively, a function could be developed to predict the attachment type based on known public addresses.

• Regarding the Markdown Syntax in HTML Attributes issue, I recommend deferring this to a secondary follow-up task. Currently, there is no clear path forward that guarantees a timely resolution without potentially delaying our primary task. Without a definitive ETA for devising and implementing a solution, prioritizing this fix would put a halt on the current feature

I look forward to your feedback on these proposals to ensure we can move forward effectively.

[melvin-bot]

@kidroca Whoops! This issue is 2 days overdue. Let's get this updated quick!