Page MenuHomePhabricator

[Spike] [BUG] POTD Gallery doesn't load, crashes upon share
Closed, ResolvedPublic1 Estimated Story PointsBUG REPORT

Description

Investigate for 1 hour to see if it's an easy fix. If not, document what you did & bring it back to Triage

Steps to reproduce

  1. From Explore, tap Picture of the Day
  2. Image doesn't load (bug 1).
  3. Tap share button, crashes (bug 2)

Expected results

Image should (eventually) finish loading, and while loading share button should be disabled.

Actual results

Image never loads. When in spinner / loading state, share button crashes.

Screenshots

Environments observed

App version: 8.0.1 (6042)
OS versions: 26.2.1
Device model: iPhone 12 Pro Max
Device language: EN

Event Timeline

GOlson-WMF triaged this task as Medium priority.May 12 2026, 5:17 PM
HNordeenWMF renamed this task from [BUG] POTD Gallery doesn't load, crashes upon share to [Spike] [BUG] POTD Gallery doesn't load, crashes upon share.May 12 2026, 5:18 PM
HNordeenWMF updated the task description. (Show Details)
HNordeenWMF added a subscriber: ARamadan-WMF.

Other user reports here: T425656: Picture of the Day widget opens black screen. Closed as duplicate fo rnow, but re-open if you think it's separate issues

+1 user :
When I open the Explore section, today's picture is displayed, but when I tap it, the screen goes to the black screen shown above, and the spinning circle just keeps going on and it never opens. I've updated the Wikipedia app and cleared the cache, but it hasn't improved.

Version: WikipediaApp/8.1.0.6052 (iOS 26.4.2; Phone)

image0 (12).png (1,170×2,532 px, 159 KB)

Seddon raised the priority of this task from Medium to Unbreak Now!.May 15 2026, 8:36 PM
Seddon renamed this task from [Spike] [BUG] POTD Gallery doesn't load, crashes upon share to [Spike] [BUG] All images breaking on iOS , crashes upon share.May 15 2026, 8:41 PM
Seddon renamed this task from [Spike] [BUG] All images breaking on iOS , crashes upon share to [Spike] [BUG] All images breaking on iOS.

Change #1287940 had a related patch set uploaded (by Subramanya Sastry; author: Seddon):

[operations/mediawiki-config@master] Revert "Enable wgTrackMediaRequestProvenance on remaining Wikipedias"

https://gerrit.wikimedia.org/r/1287940

Change #1287940 merged by jenkins-bot:

[operations/mediawiki-config@master] Revert "Enable wgTrackMediaRequestProvenance on remaining Wikipedias"

https://gerrit.wikimedia.org/r/1287940

Mentioned in SAL (#wikimedia-operations) [2026-05-15T20:55:47Z] <jforrester@deploy1003> Started scap sync-world: Backport for [[gerrit:1287940|Revert "Enable wgTrackMediaRequestProvenance on remaining Wikipedias" (T425580)]]

Mentioned in SAL (#wikimedia-operations) [2026-05-15T20:57:45Z] <jforrester@deploy1003> jforrester, seddon: Backport for [[gerrit:1287940|Revert "Enable wgTrackMediaRequestProvenance on remaining Wikipedias" (T425580)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-05-15T21:03:30Z] <jforrester@deploy1003> Finished scap sync-world: Backport for [[gerrit:1287940|Revert "Enable wgTrackMediaRequestProvenance on remaining Wikipedias" (T425580)]] (duration: 07m 43s)

The root cause has been traced to URL manipulation in the Wikipedia iOS app, which tries to change the size of images (I guess for its lightbox/mediaviewer equivalent), but was doing so without a URL parser and could corrupt the string when it contains a query string.

This is being fixed at https://github.com/wikimedia/wikipedia-ios/pull/5880

However this will likely break again if we require signed hashes in the provenance parameter, because it is still manipulating URLs instead of using the images from the Parser and/or imageinfo API.

But I can also see why that makes sense, because the ones on the page are relatively low resolution, and while it presumably does call the imageinfo API already, we probably don't want that to vary by phone size and orientation without CDN caching. So that's something we'll want to think about.

I think we should improve the imageinfo API (T426246) so that consumers like MediaViewer (desktop site), InstantCommons, and the mobile apps can efficiently obtain metadata and sizes in a way that's CDN cacheable and without needing to vary by screen size (basically: return a set of URLs that the client picks from).

Change #1288925 had a related patch set uploaded (by Krinkle; author: Seddon):

[operations/mediawiki-config@master] Revert "Enable wgTrackMediaRequestProvenance on Commons"

https://gerrit.wikimedia.org/r/1288925

Change #1288925 merged by jenkins-bot:

[operations/mediawiki-config@master] Revert "Enable wgTrackMediaRequestProvenance on Commons"

https://gerrit.wikimedia.org/r/1288925

Hi all, this is looking better. I'm still seeing the original bug (picture of the day not loading), but the widespread image loading issue is better. I still notice a couple of things when digging:

Wikifeeds still returns the query parameters in its image value:

https://en.wikipedia.org/api/rest_v1/feed/featured/2026/05/18

Screenshot 2026-05-18 at 3.21.56 PM.png (1,626×198 px, 64 KB)

Though I don't think this alone is causing it. It looks like we do this followup call to get image information directly from the MediaWiki API. When I strip the query parameters in this response, that fixes the POTD loading bug.

https://commons.wikimedia.org/w/api.php?action=query&format=json&generator=images&iiextmetadatafilter=License%7CLicenseUrl%7CLicenseShortName%7CImageDescription%7CArtist&iiextmetadatalanguage=en&iiextmetadatamultilang=1&iiprop=url%7Cextmetadata%7Cdimensions&iiurlwidth=500&prop=imageinfo&rawcontinue=&titles=Template:Potd/2026-05-18

Screenshot 2026-05-18 at 3.24.41 PM.png (1,637×146 px, 72 KB)

cc @JTweed-WMF Do we need to do a different rollback for Commons? Thanks 🙏

Tsevener lowered the priority of this task from Unbreak Now! to High.May 18 2026, 8:44 PM
Tsevener renamed this task from [Spike] [BUG] All images breaking on iOS to [Spike] [BUG] POTD Gallery doesn't load, crashes upon share.May 18 2026, 8:49 PM

Mentioned in SAL (#wikimedia-operations) [2026-05-18T21:31:09Z] <krinkle@deploy1003> Started scap sync-world: Backport for [[gerrit:1288925|Revert "Enable wgTrackMediaRequestProvenance on Commons" (T414338 T425580)]]

Mentioned in SAL (#wikimedia-operations) [2026-05-18T21:32:56Z] <krinkle@deploy1003> seddon, krinkle: Backport for [[gerrit:1288925|Revert "Enable wgTrackMediaRequestProvenance on Commons" (T414338 T425580)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

@JTweed-WMF Forgive the out-of-date comment, I was behind on the Slack request.

Keeping it there for myself to check the API calls once the rollback is complete.

Mentioned in SAL (#wikimedia-operations) [2026-05-18T21:42:39Z] <krinkle@deploy1003> Finished scap sync-world: Backport for [[gerrit:1288925|Revert "Enable wgTrackMediaRequestProvenance on Commons" (T414338 T425580)]] (duration: 11m 29s)

Tsevener set the point value for this task to 1.May 19 2026, 5:16 PM

Picking this back up to investigate the crash part. The endless loading is now fixed, but I'm going to disable the share button while it loads so we don't see crashes.

Unable to reproduce the crash on 8.2.0 (6070)
Tested on:
iPhone 16, iOS 26.4.2
iPhone SE, iOS 26.4.2
iPad Air 11 inch, iPadOS 26.3.1