Page MenuHomePhabricator

Image recs: Preview often does not show the added image without scrolling (especially when in infobox)
Closed, DeclinedPublicBUG REPORT

Assigned To
None
Authored By
ABorbaWMF
Apr 23 2024, 8:31 PM
Referenced Files
F48664741: Screenshot 2024-04-25 at 2.41.46 PM
Apr 25 2024, 7:53 PM
F48664728: Screenshot 2024-04-25 at 2.41.43 PM
Apr 25 2024, 7:53 PM
F48332637: IMG_5977.PNG
Apr 23 2024, 8:31 PM
F48332611: IMG_5976.PNG
Apr 23 2024, 8:31 PM
F48332588: IMG_5975.PNG
Apr 23 2024, 8:31 PM
F48332557: IMG_5974.PNG
Apr 23 2024, 8:31 PM

Description

Steps to replicate the issue (include links if applicable):

  • Tap on Add an Image
  • Tap on Yes
  • Add a caption and tap on Next
  • View the preview

What happens?:
Often the added image is not visible to the user without scrolling the preview. This seems to happen in many cases, but I have noticed that images added to an infobox reproduce this consistently.

What should have happened instead?:
The image should be visible

Software version :
Tested on 7.4.11 (76)

Other information (browser name/version, screenshots, etc.):

IMG_5974.PNG (2×1 px, 558 KB)

IMG_5975.PNG (2×1 px, 374 KB)

Preview 1st view
IMG_5976.PNG (2×1 px, 243 KB)

After scrolling
IMG_5977.PNG (2×1 px, 1 MB)

Event Timeline

Just some background here:

We don't really have control over this client-side. We are inserting the image at the top of the wikitext (after templates) for all languages, and the backend edit preview response serves it up to us in this order occasionally. I was able to quickly reproduce this ordering on Android as well for Spanish Wikipedia:

Screenshot 2024-04-25 at 2.41.43 PM (1×1 px, 290 KB)

Screenshot 2024-04-25 at 2.41.46 PM (1×1 px, 438 KB)

The preview endpoint is POST to https://en.wikipedia.org/api/rest_v1/transform/wikitext/to/mobile-html/{title}

Android is going an extra step and inserting the image directly into select infoboxes for EN-only. iOS is not doing this (nice-to-have task). If we're seeing this behavior more often on iOS than Android for EN, that's probably why.

We decided not to pick up the task that would address this (T359134) at this time.