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 @ 💬)

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.

Yes, but my effort in this direction has turned into kind of a project. I've sent #2077 to prepare for this; PTAL.

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 · 2026-01-26T20:35:41Z

Thanks for the review! Revision pushed, and this one is atop #2100 which I've just sent separately.

gnprice

Thanks! One substantive comment and one follow-up.

gnprice · 2026-01-26T21:04:07Z

lib/model/content.dart

+    final alt = imgElement.attributes['alt'];
+    if (alt == null) return null;


Can this be made optional? If a server for some reason starts sending these without alt, it seems like we can tell how we'd want to display that.

Aha it's actually already optional in the content node class, but we don't need this null return here.

gnprice · 2026-01-26T21:16:21Z

lib/widgets/content.dart

+    if (resolvedOriginalSrc != null) {
+      result = GestureDetector(
+        onTap: () {
+          Navigator.of(context).push(getImageLightboxRoute(


Perhaps as a followup PR, so while this is still fresh in mind but without blocking us merging and releasing the feature: this InlineImage is doing very nearly the same things as the MessageImagePreview widget, especially here in the _buildContent method, but the code looks more different than it is. It'd be nice to refactor them to look more similar so that the real differences are easier to spot.

Ideally, the logic here in _buildContent would become a helper widget that's shared between InlineImage and MessageImagePreview.

chrisbobbe · 2026-01-26T21:35:41Z

Thanks! Revision pushed, PTAL, and I'll start looking at that followup now.

gnprice · 2026-01-26T21:51:53Z

lib/widgets/content.dart

+          child: Tooltip(
+            message: node.alt,


Is it OK here if node.alt is null?

It looks like Tooltip has an assert that would reject that. The parameter is nullable only because there's an alternative parameter richMessage.

Good catch; will fix.

chrisbobbe · 2026-01-26T21:55:47Z

(Noting here so I don't forget—I believe I've debugged the lightbox-hero-not-working issue and will include the fix in my next revision.)

chrisbobbe · 2026-01-26T22:05:14Z

Thanks! Revision pushed.

gnprice · 2026-01-26T22:07:10Z

lib/widgets/content.dart

+    final size = BoxConstraints(maxHeight: maxHeight)
+      .constrainSizeAndAttemptToPreserveAspectRatio(imageSize);
+
+    Widget child = _buildContent(context, size: size);


This version is missing a ColoredBox, no?

Eep, yes, thanks for the catch.

gnprice · 2026-01-26T22:08:23Z

lib/widgets/content.dart

+        },
+        child: LightboxHero(
+          messageImageContext: context,
+          src: resolvedOriginalSrc,


Aha — so the issue with the hero here was that it needed src to match that passed to getImageLightboxRoute.

Fixes zulip#1913.

chrisbobbe · 2026-01-26T22:12:44Z

Yep, that's right! Revision pushed.

gnprice · 2026-01-26T22:17:30Z

Thanks! All looks good; merging.

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 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

chrisbobbe mentioned this pull request Jan 13, 2026

content: Record href and src straightforwardly on ImagePreviewNode #2077

Merged

timabbott mentioned this pull request Jan 21, 2026

Implement CommonMark image syntax zulip/zulip#28912

Open

2 tasks

chrisbobbe mentioned this pull request Jan 26, 2026

Assimilate image-preview parsing to intended inline-image logic #2100

Merged

chrisbobbe force-pushed the pr-inline-images branch from 8157751 to 2d5e9a6 Compare January 26, 2026 20:35

gnprice reviewed Jan 26, 2026

View reviewed changes

chrisbobbe force-pushed the pr-inline-images branch from 2d5e9a6 to 2a09dba Compare January 26, 2026 21:34

gnprice reviewed Jan 26, 2026

View reviewed changes

chrisbobbe force-pushed the pr-inline-images branch from 2a09dba to 2066420 Compare January 26, 2026 22:04

gnprice reviewed Jan 26, 2026

View reviewed changes

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

5453fc7

Fixes zulip#1913.

chrisbobbe force-pushed the pr-inline-images branch from 2066420 to 5453fc7 Compare January 26, 2026 22:11

gnprice merged commit 5453fc7 into zulip:main Jan 26, 2026
1 check passed

chrisbobbe deleted the pr-inline-images branch January 26, 2026 22:17

chrisbobbe mentioned this pull request Jan 27, 2026

Write inline-image widget code more like image-preview widget code #2102

Merged

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

		final alt = imgElement.attributes['alt'];
		if (alt == null) return null;

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

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!

Choose a reason for hiding this comment

Uh oh!

chrisbobbe commented Jan 26, 2026

Uh oh!

gnprice 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 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Uh oh!

chrisbobbe commented Jan 26, 2026

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 26, 2026

Uh oh!

gnprice commented Jan 26, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

chrisbobbe Jan 10, 2026 •

edited

Loading

chrisbobbe commented Jan 26, 2026 •

edited

Loading