content: Support inline images using the ![alt text](url) syntax #2067

chrisbobbe · 2026-01-08T01:44:35Z

Fixes #1913.

This relies on an API guarantee that's implicit in the web PR zulip/zulip#36226, but I've left a PR review suggesting more explicitness: zulip/zulip#36226 (review) . In particular, this assumes that src in the inline-image HTML will be a thumbnail URL, i.e. one that starts with '/user_uploads/thumbnail/'.

See also some followup issues:

Screenshots coming soon. 🙂

chrisbobbe · 2026-01-08T02:04:19Z

cc @alya

Showing a large image being shrunk, and center-aligned vertically in the flow of text:

Web (CZO 2026-01-07)	Mobile

Showing a small image:

There's a discrepancy here, but it's web's bug: it blows up the image so that it uses more pixels than the image has data for, and it's blurry. I started a discussion: #design > Inline images blown up and blurry @ 💬

Web (CZO 2026-01-07)	Mobile

Showing images in a table:

The table is wider than available space on mobile; I've included a second mobile screenshot where I scrolled the table to see the rest of it.

Web (CZO 2026-01-07)	Mobile

chrisbobbe · 2026-01-08T23:37:57Z

Revision pushed. Having seen @timabbott's comment zulip/zulip#36226 (comment) , I've relaxed the "image-loading-placeholder" case in the parser so that it doesn't expect src to be a thumbnail URL.

rajveermalviya

Thanks @chrisbobbe! All LGTM, and tests great on a local server (except I couldn't test the loading state, not sure if there's an easy way to do that).

Moving over to Greg's review.

gnprice · 2026-01-09T22:04:48Z

lib/model/content.dart

+//|//////////////////////////////////////////////////////////////
+// Helpers for both [_ZulipInlineContentParser] and [_ZulipContentParser].
+
+
+final _imageDimensionsRegExp = RegExp(r'^(\d+)x(\d+)$');


nit: put helpers above rather than below (that's how this parser code is organized in general)

gnprice · 2026-01-09T22:08:52Z

lib/model/content.dart

+    final dimensionsMatch = _imageDimensionsRegExp.firstMatch(originalDimensions);
+    if (dimensionsMatch == null) return null;
+    final originalWidth = int.tryParse(dimensionsMatch.group(1)!, radix: 10)?.toDouble();
+    final originalHeight = int.tryParse(dimensionsMatch.group(2)!, radix: 10)?.toDouble();
+    if (originalWidth == null || originalHeight == null) return null;


This is some nontrivial logic that feels like it's doing very much the same thing as the other site where this regexp is used. Can that be factored out as a helper function?

(The helper can return an ad-hoc record type with width and height)

gnprice · 2026-01-09T22:17:03Z

lib/model/content.dart

+    final originalSrc = imgElement.attributes['data-original-src'];
+    if (originalSrc == null) return null;


I think we decided in the chat thread that these images might not be thumbnailed. This isn't yet…

… ah I see, this revision is from before we decided that 🙂. I'll hold off on reviewing further for now, then.

(see #api design > HTML pattern for truly inline images @ 💬)

The instance will always have a format we can fall back to, i.e., defaultFormatSrc, so there's no need for this method's return type to be nullable.

Fixes zulip#1913.

chrisbobbe · 2026-01-10T00:43:12Z

Thanks! Revision pushed, and I've commented at #api design > HTML pattern for truly inline images @ 💬 on how the parser is more permissive of forms that current servers don't produce.

gnprice · 2026-01-10T01:15:28Z

lib/model/content.dart

+    return InlineImageNode(
+      loading: loading,
+      src: thumbnailSrc != null
+        ? InlineImageNodeSrcThumbnail(thumbnailSrc)
+        : InlineImageNodeSrcOther(src),
+      alt: alt,
+      originalSrc: originalSrc,
+      originalWidth: originalWidth,


Oh I see, we do use the original size, naturally enough.

Also apparently alt; I'd missed that we use it in two places.

we never look at any of these other fields on InlineImageNode, right?

We use data-original-dimensions, when present, to avoid layout shifts when transitioning out of the loading state. I think data-original-dimensions will still be present in the loading state, from current servers? Because current servers only intend to operate on uploaded images, and we know the dimensions of those. This is supported by the API doc in zulip/zulip#36226:

For image elements presented in Markdown syntax, this placeholder structure is used: ```html <img alt="example image" class="inline-image image-loading-placeholder" data-original-content-type="image/png" data-original-dimensions="1050x700" data-original-src="/user_uploads/path/to/example.png" src="/path/to/spinner.png"> ```

gnprice · 2026-01-10T01:22:03Z

lib/model/content.dart

+      final dimensionsMatch = _imageDimensionsRegExp.firstMatch(originalDimensions);
+      if (dimensionsMatch != null) {
+        originalWidth = int.tryParse(dimensionsMatch.group(1)!, radix: 10)?.toDouble();
+        originalHeight = int.tryParse(dimensionsMatch.group(2)!, radix: 10)?.toDouble();
+      }


This is meant to use the new helper, right?

gnprice · 2026-01-10T01:23:41Z

lib/model/content.dart

+    final src = imgElement.attributes['src'];
+    if (src == null) return null;
+    final animated = imgElement.attributes['data-animated'] == 'true';
+    ImageThumbnailLocator? thumbnailSrc;
+    if (src.startsWith(ImageThumbnailLocator.srcPrefix)) {
+      final srcUrl = Uri.tryParse(src);
+      if (srcUrl == null) return null;
+      thumbnailSrc = ImageThumbnailLocator(defaultFormatSrc: srcUrl, animated: animated);
+    }


And this is some other logic that seems very similar to some code we already have for the block images. It'd be good to either deduplicate, or if that's annoying for some reason then to adjust the two to be written as similarly as possible — that way one can look at the two of them and work out if there are any subtle discrepancies in behavior that we might not intend.

gnprice · 2026-01-10T01:26:02Z

lib/model/content.dart

+class InlineImageNode extends InlineContentNode {
+  const InlineImageNode({
+    super.debugHtmlNode,
+    required this.loading,
+    required this.src,
+    required this.alt,
+    required this.originalSrc,
+    required this.originalWidth,
+    required this.originalHeight,
+  });


Can we unify this with ImagePreviewNode, by giving them a common base class that supplies most of these fields? It seems like they have much the same data on them.

That might also help with unifying more of the parsing logic for them.

gnprice · 2026-01-10T01:34:32Z

lib/widgets/content.dart

+      // Don't let tall, thin images take up too much vertical space,
+      // which could be annoying to scroll through…
+      BoxConstraints(maxWidth: maxHeight * aspectRatio, maxHeight: maxHeight)


Suggested change

// Don't let tall, thin images take up too much vertical space,

// which could be annoying to scroll through…

BoxConstraints(maxWidth: maxHeight * aspectRatio, maxHeight: maxHeight)

// Don't let tall, thin images take up too much vertical space,

// which could be annoying to scroll through…

BoxConstraints(maxHeight: maxHeight)

This seems like it matches the comment better. And I believe it has the exact same effect, producing the same result for the .enforce call below.

chrisbobbe requested a review from rajveermalviya January 8, 2026 01:44

chrisbobbe assigned rajveermalviya Jan 8, 2026

chrisbobbe added the maintainer review PR ready for review by Zulip maintainers label Jan 8, 2026

chrisbobbe requested a review from alya January 8, 2026 02:04

chrisbobbe added the product review Added by maintainers when a PR needs product review label Jan 8, 2026

chrisbobbe force-pushed the pr-inline-images branch from 941e8c9 to 301415e Compare January 8, 2026 23:35

rajveermalviya approved these changes Jan 9, 2026

View reviewed changes

rajveermalviya added integration review Added by maintainers when PR may be ready for integration and removed maintainer review PR ready for review by Zulip maintainers labels Jan 9, 2026

rajveermalviya assigned gnprice and unassigned rajveermalviya Jan 9, 2026

rajveermalviya requested a review from gnprice January 9, 2026 21:35

gnprice reviewed Jan 9, 2026

View reviewed changes

chrisbobbe added 4 commits January 9, 2026 15:31

content [nfc]: Refactor img.emoji parsing code

a80fdf4

image [nfc]: Fix return type of ImageThumbnailLocatorExtension.resolve

7a61312

The instance will always have a format we can fall back to, i.e., defaultFormatSrc, so there's no need for this method's return type to be nullable.

content [nfc]: Bring out a helper for upcoming inline-image feature

4c32732

content: Support inline images using the ![alt text](url) syntax

8157751

Fixes zulip#1913.

chrisbobbe force-pushed the pr-inline-images branch from 301415e to 8157751 Compare January 9, 2026 23:58

gnprice reviewed Jan 10, 2026

View reviewed changes

		final originalSrc = imgElement.attributes['data-original-src'];
		if (originalSrc == null) return null;

content: Support inline images using the ![alt text](url) syntax #2067

Are you sure you want to change the base?

content: Support inline images using the ![alt text](url) syntax #2067

Uh oh!

Conversation

chrisbobbe commented Jan 8, 2026

Uh oh!

chrisbobbe commented Jan 8, 2026

Uh oh!

chrisbobbe commented Jan 8, 2026

Uh oh!

rajveermalviya left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrisbobbe commented Jan 10, 2026

Uh oh!

This comment was marked as resolved.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrisbobbe Jan 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

chrisbobbe Jan 10, 2026 •

edited

Loading