Image lightboxing does not respect manual resizing or [grid] tags

bug
1

Priority/Severity: Low.
Platform: Confirmed in Firefox 127.0 on Windows 10 and Chrome 125.0.6422.165 on Android 14.
Description: See below.
Reproducible steps: Upload an image with a resolution of 690×500 pixels or lower and either manually resize it (e.g. ![|336x456,x150](upload://uoNNF6SaHfaM6bRapNRZoeKQqjU.png)) or put it in a [grid] (e.g. [grid] ![|336x456](upload://uoNNF6SaHfaM6bRapNRZoeKQqjU.png) [/grid]).

Expected behavior

The way lightboxing works in Discourse is meant to work is, if the image has been shrunk to fit in the post, it is lightboxed so that it can be clicked on to see the full resolution.

The issue

There’s a bug in how this is currently implemented: It only compares the image’s original resolution to the website’s “max image width” and “max image height settings” (by default 690×500 pixels), ignoring manual resizing and image grids. This has the consequence that images that have been shrunk may not be lightboxed, if they’re below [max image width]×[max image height].

Manual resizing[1]

Here’s an example of lightboxing failing to apply when images have been shrunk manually – mouse over the following images, and you’ll see that they’re inconsistently lightboxed; click on a lightboxed one and you’ll see that some of them don’t appear when pressing left or right:[2]

557×1169 463 KB
678×811 395 KB
771×900 324 KB

Image grids

The issue in image grids is that grids practically always resize – and often even crop – the images, which makes it a problem when they then can’t be clicked to see the full image.




The solution

An updated proposed solution can be found in the discussion below.

The originally proposed solution… The solution would be to ensure that:
  1. Lightboxing compares the image’s size on the page to its original resolution, and that
  2. Images in grids are always lightboxed.

As I understand it, applying the lightboxes is done client-side, so I don’t think it should be prohibitively difficult, at least!

  1. This part of the issue has been mentioned on the forum before, a thread in which more or less the same conclusion for what the solution would be was drawn. ↩︎

  2. Originally, this caused significant formatting issues due to an issue I reported separately, but at the time of editing this post and writing this bit, it has already been fixed. ↩︎

6 Likes
2

One thought I had was this: Is there a reason not to lightbox all images? At least images that could comfortably fit the info bar and the little “expand” icon on mobile without covering up too much of the image. The lightbox has value in two ways beyond just allowing you to see the full-res image:

  • It displays the alt text (crucially, something far more likely to be supplied by a poster than title text due to alt text being pre-filled and the syntax for title text being more obscure), and
  • The image isn’t omitted when flipping through the images after clicking on a lightbox.

Is there a reason not to lightbox images that can be seen in full?

One option might be to simply (in addition to lightboxing all images in grids) lightbox every image above a certain size on the page – say, above 72×72 pixels or so (I’m thinking in lines here – anything above ~3 lines in size). What do you think?

1 Like
8

I agree and have brought up this issue in the past as you linked to in your OP Some images don't lightbox? - #3 by piffy

The issue as I see it is that the “resized and lightboxed” settings are coupled.

Screenshot_20240619_044925_Chrome
Screenshot_20240619_044925_Chrome1080×820 117 KB

Ideally I would like the resize settings to be similar to these defaults of 690x500px but the lightbox settings to be closer to 72x72px (like anything bigger than a large emoji or “sticker” sized image).

It seems like the primary intention of the lightbox is to view an unscaled version of the image but I definitely use it more as a carousel-style gallery. That’s why it’s a bit jarring when something 502px tall is treated differently from something 499px tall especially when they are in the same grid.

1 Like
9

I think that’s a perfect encapsulation of what I was thinking – that’s the only use case where you wouldn’t want a lightbox, isn’t it: when the image is either more “part of the text” or “part of the post’s formatting”.

I think that’s a better solution overall – to separate the “lightbox images above the size […]” out into its own setting with a much lower default. It would make sense for it to differ from the current implementation in two further ways:

  • It should judge by the size on the page, as opposed to the original size of the image.
  • It should probably need to exceed both dimensions, as opposed to just one – I can’t quite picture a use case where you would want an image that’s, say, 690×10 pixels (on the page) to be lightboxed.

As a note on use cases, I sometimes include small images in an emoji-like fashion – but they’re high-resolution, so that they won’t be blurry on high-DPI screens. For example: ! This image should not be lightboxed, since 1) it’s an emoticon, but more importantly, 2) the little expansion icon in the bottom right corner would cover up most of it on mobile. At present, it isn’t lightboxed because the high-res original image is below 690×500 pixels in size (372×468 pixels, to be exact), but it shouldn’t be lightboxed despite having been scaled down – the truly salient criterion to judge by is what its size is on the page.

1 Like