T378783 reports a similar visibility issue with the volume slider in dark mode.

Makes sense, thanks @HasanAkgun_WMDE! The task had already been closed while I was testing so I just wanted to share the findings anyway. The current behavior is good enough as is. Thanks for following up!

As far as I can tell, this still reproduces because GET /sign_in unconditionally renders the login-error page , so any direct visit shows the error with no way to log in.

For me days=3, logged in: now loads fine (1 result) and days=7, logged in: times out.

This seems to be a pre-existing bug in ExpandRelativeAttrs::expandRelativeAttrs() that was exposed by the enwiki Parsoid Read Views rollout (T430194). This breaks footnote navigation and any gadget that parses the href (like Reference Tooltips) on pages with percent-encoded characters in their title.

I think the "You do not have permission" message is a bit misleading here since the user actually has the right but only needs to reauthenticate.

Looks like a side effect of Iae4182f. I think using RIGOR_FULL in checkPermissions() (so the form loads) and handling getReauthOperation() in onSubmit() (redirect to login when reauth is needed) might fix this.

This looks like a duplicate of T373276.

I wasn't able to reproduce this, but Logstash does show intermittent DBQueryTimeoutError entries for ORES-filtered Special:RecentChanges queries. These errors have been appearing for a while and are not limited to simplewiki. T276699 seems to describe the same symptoms on enwiki.

I looked into this and it seems to be caused by Gerrit 1298341 (T425029). The new first_edit_dt field passes cross-wiki users through the local ActorStore, which corrupts the actor cache for the log entry that is written right after.

It looks like RedirectResolvingEntityLookup was designed to resolve only one redirect level, and the WikiProject linking feature (T421850) exposed this by calling getEntity() on pages that can be double redirects.

In T426358#12016059, @Jdlrobson wrote:

@HakanIST I'd suggest that we DO NOT output data-footer for skins who define footer in menu definition in getTemplateData. That would save a lot of processing power. It would also help with us migrating skins away from data-footer usage in templates in future. What do you think?

In T427611#12015397, @sbassett wrote:

In T427611#12014960, @HakanIST wrote:

FWIW, I tested v5-alternative-2 on a local MW 1.47 instance and both SVG and MAP links generated correctly as absolute URLs for me.

Interesting. I'm testing on a fairly recent version of MW core master (just updated it actually), recent ext:timline w/ security patches from T426631 applied as well and ploticus 2.42-May2013. I get the strange image map and SVG linking issues I mentioned above for the Stalin text in the mediawiki.org example every time.

FWIW, I tested v5-alternative-2 on a local MW 1.47 instance and both SVG and MAP links generated correctly as absolute URLs for me.

Looking at Logstash, the LogicException dropped to zero on Jun 11 after the remaining delayed jobs from before the fix expired.

The fix is live since wmf.5. It reduced the warning rate from ~650,000/day down to ~730/day.

Thanks both for the context. No rush on the review from my side, I can rebase whenever needed. Also, I can help with wikibugs testing or anything else if that is useful.

Bug fixed by Change Ida7cef,. The HK file on Commons now returns timestamp and user for the filemissing revision.

In T426802#11991964, @JJMC89 wrote:

Yea, I guess the new issue here was that the below case had neither filemissing or metadata.

{
  "filehidden": true
}

Correct, this fix addresses both the filemissing-without-metadata and the filehidden-without-metadata cases, now deployed to all wikis.

Related to T414805 AddImageUtils.getImageRenderData() requests non-standard thumbnail widths (e.g. 320px) which now return HTTP 400

This looks related to T216265, which requests the ability to filter Wikibase edits in Recent Changes by type of change (including sitelinks).

Note: buildContentNavigationUrlsInternal() gives ca- prefix to footer items added via Universal hook without explicit id. Worth a follow-up?

This looks like it may have been introduced in rEMMV8022a88a7efc (T426225), which removed the onGetPreferences() hook while migrating carousel preferences to BetaFeatures. The desktop multimediaviewer-enable toggle was also registered in that same method and seems to have been unintentionally removed along with it.

It appears the tool has been down since the Dec 2025 disk space intervention T395020: zoomviewer uses an unreasonable amount of disk space

The linked patch decodes the src before comparison, which should cover all the examples here

Thanks @dcausse, that is very helpful. I think your suggestion of using haswbstatement: with a configurable list of common SDC properties is feasable. That should be good enough for a delete page warning.

Thanks for the feedback @Lucas_Werkmeister_WMDE!

Tagging @Raymond_Ndibe

I've a patch proposal that adds two things to Wikibase:

I think this is a double-escaping in FormatMetadata::langItem() PNGs store Model/Make as _type: lang via PNGMetadataExtractor, so they go through langItem() which calls htmlspecialchars() on the already-formatted exifMsg() output. JPEGs have plain strings and skip langItem() entirely.

One thing to keep in mind: the relative wiki links (like Special:MyLanguage/Foo) would need to be rewritten to absolute URLs before the $wgUrlProtocols check, otherwise fixMap()-style filtering would strip them too.

Would it make sense to handle this the same way fixMap() already handles image map hrefs, i.e. check xlink:href values against $wgUrlProtocols, convert relative wiki links to absolute URLs (distinguishing namespace prefixes from URI schemes via NamespaceInfo), and neutralize anything else? That way both the XSS (T427611) and the relative-link regression (T428063) would be fixed without needing to route through UploadBase::verifyUpload().

I scanned about 100k recent JPEG uploads on Commons for SOF9 markers and this is the only one. It was probably an accidental export setting, not enabled by default in any common photo editor.

In T415488#11586164, @A_diehard_editor wrote:

Update: wbEntity appears in the inspect element tab when I open a MediaInfo page, so yeah, it really is a frontend rendering bug. At this point, I'm just lost.

In T416112#11849941, @jijiki wrote:

on wikikube-worker-exp1001.eqiad.wmnet under my home dir, you can find a few traces that led to SIGABRT feel free to have a look.

Tested patch locally on Docker (MediaWiki master + WikibaseMediaInfo): adding, editing, removing, and re-adding coordinate statements all work as expected. Publish button activates correctly after changes.

Likely same root cause as T427398.

In T427398#11959873, @sbassett wrote:

Just to confirm: this does not appear to be affecting all wikis. When I try similar actions on enwiki, the reauth prompts work as expected for me.

Same cross-domain security-level desync hits Special:BotPasswords, securitySensitiveOperationStatus() loops indefinitely. Logstash shows other reauth loops too.

In T427158#11956712, @Jdlrobson-WMF wrote:

The issue here seems to be in the generation of the image https://upload.wikimedia.org/wikipedia/commons/1/14/Audrey_Nuna_at_the_2026_Met_Gala_%28cropped%29.jpg?_=20260515174212 as a gray rectangle.

In T422052#11955545, @Jdforrester-WMF wrote:

The for (const claim of claims ) {…} loop would already be a no-op, though, so this shouldn't change the response? But either way, our server code shouldn't treat this as a fatal in our code. :-)

Tagged edits can be filtered in Recent Changes:

In T427093#11955525, @Jack_who_built_the_house wrote:

@HakanIST

Some follow-up: CD is one trigger (ruwiki)

Still getting them from CD? Same error text and call stack?

Created the autosuggest-sitelink tag on Wikidata and submitted a merge request that passes it to the wbsetsitelink API call.

Some follow-up: CD is one trigger (ruwiki), but only ~13% of the total. The error also shows up on Chrome with a different message (Cannot read properties of null (reading 'parentNode') + newFromJSON in stack). Combined, it's ~830 hits / 7 days from ~57 unique UAs, mostly repeat hits from a few users.

I tried to reproduce this locally with an iOS Simulator and a standalone page using the same CSS from modalOverlay.vue.

The issue appears to have been a transient outage, the service has since recovered on its own.

I think bug is in StatementPanel.js line 160:

In T420341#11952480, @KTT-Commons wrote:

I must say I'm disappointed with the current progress, so I did some experiment on English Wikisource. I uploaded this file on English Wikisource (which is an exact copy of this file on Commons.

The result? The exact same problem is recreated. Purge? No use. Hard purge? No use. Null edit? No use. Dummy file uploading? No use. Is it somehow related to individual files?

Hopefully these additional information (that the same problem exists across projects) would be useful to resolving this problem, thank you.

I was looking at logstash for warning patterns and spotted one from WikifunctionsClientStore (~9K warnings per 12h). Submitted a fix here: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/1293081

This seems related to T423818. As of now, the API returns 404 for May 22 onward and the last dump file is pageviews-20260522-110000.

This might be related to T421524 and the POC in https://gerrit.wikimedia.org/r/c/1286443. Both involve srcset handling for images smaller than the requested thumbnail size. The POC addresses CSS upscaling, but this task seems to additionally need a fix in processResponsiveImages() to avoid setting an incorrect srcset 2x when the original image cannot fulfill it.

I can reproduce this with the image in the task. It seems related to srcset. This image is 832px wide but displayed at 480px width, so a valid 2x source would need 960px. But Linker::processResponsiveImages() still sets the original (832px) as srcset 2x. The browser gets a density descriptor that does not match the actual image size and fails to render it. Removing srcset from the element makes the image visible immediately.

The above MR covers maniphest.info -> maniphest.search.

I wasn't able to reproduce this: hovercards on all three pages load thumbnails correctly (960px, via /page/summary/), and the /page/html/ responses now only contain standard thumbnail sizes.

I can reproduce this. The broken OSM link seems related to T401606: the static mapframe container is an <a> element, and the attribution links inside it are nested <a> tags, so clicks go to fullscreen instead of the OSM copyright page. The missing scale bar is expected since inline maps are static PNGs without Leaflet controls.

Tagging @Andrew since he has recent commit on the wikitech-static-docker repo. The GitLab CI pipelines have been failing since May 18.

Still happening as of today (May 2026). The login loop messages continue in #wikimedia-external-links.

This looks closely related to (and possibly a duplicate of) T239213, which describes the same imageinfo API behavior for filemissing revisions.

Then, maybe adding VISUALENHANCEMENTS to that conflict list would help here.

In T427093#11949615, @Jdlrobson-WMF wrote:

Thanks for debugging. Is there any way we can make it more obvious in stack traces when Convenient Discussions is the culprit and not DiscussionTools? Would make debugging these helpful.

Thanks for the quick fix @Strainu! I think addCharacters() might still be affected though. The symbols page seems to be lazy-loaded, so it is not ready yet when the hook fires. I still see this in the console on edit pages:

Excluding WikimediaCustomizations works. Looks like the donoridentification-donorbadge handler has TestKitchen.ExperimentManager as a services dependency instead of optional_services.

I looked into this a bit. It seems like the Convenient Discussions gadget is the trigger here, at least for ru.wikipedia.org cases.

This might just be expected behavior, as the page likely accumulated heavy transclusions over time and eventually crossed server limits once the cache was invalidated and the cumulative parse time had to be paid all at once.

The file seems to be a double redirect on Commons; passing redirects=1 to the API might help.

Here's the diff via API:

Looks like a side effect of the T424908 fix (Gerrit 1282367). It removed the isAutoGlobal() bypass from isGlobalizablePreference() but saveFormData() still unconditionally accesses $formData[$name] for every auto-global.

This seems related to T331483, specifically T359221. These modules/templates emit literal HTML headings (<h2> etc.), which Parsoid marks as stx="html" and isWrappableHeading() in WrapSectionsState.php skips them, so no TOC is generated.

In T419172#11933150, @Michael wrote:

Sorry, I totally missed your comment here! I think in my comment above I came to the same conclusion as you did. Do you want to take on the next step of fixing this?

No problem, added the isNamed() guard at the top of onBeforePageDisplay() as you suggested.

I looked into this a bit. Two things I noticed:

I'd like to propose removing istype-depicts from KIND_TO_SOURCE entirely and also addressing the FIXME by skipping suggestions where all kinds are unrecognized (instead of assigning a default source). This way depicts-only suggestions get silently skipped rather than crashing, while mixed-kind suggestions still work. I can submit a patch if this sounds reasonable.

In T425861#11928374, @Nylki wrote:

@HakanIST Hm, did you perhaps mean to comment in a different ticket? Not sure this is related. In fact I'd close this one, as the incident ( T425758 ) has been resolved.

Still seeing IllegalArgumentException from out-of-range coordinates in wikibase:box queries. One relatively low-effort improvement might be validating coordinate bounds at the proxy layer before queries reach Blazegraph.

I checked why createaccount is missing from the portlet data. It seems to be because of SUL3: on local wikis, SharedDomainHookHandler::onAuthManagerFilterProviders() filters out CentralAuthPrimaryAuthenticationProvider (TYPE_CREATE), leaving only CentralAuthRedirectingPrimaryAuthenticationProvider (TYPE_NONE). This makes canCreateAccounts() return false, so SkinTemplate.php:537 never adds createaccount to the portlet data.

In T426294#11923289, @Jdlrobson-WMF wrote:

@HakanIST can you point me to the code that is adding the account link without text?
I don't think this is a bug with Minerva. I think Minerva is making a reasonable expectation about what a link should be so I want to understand it better!

This is possibly a duplicate of T422861.

This seems to be the same pattern as T401400 (Vector).

This is still ongoing. I tried to reproduce on a real iPhone (Safari, Chrome iOS, and GSA) and on the iOS Simulator but could not trigger it. Likely bot traffic as Jdlrobson noted.

Tested the Gerrit patch locally, all tests pass. The Clover.*West.*Virginia case now correctly extracts all 12 trigrams. Great fix!

For reference, this would be stricter than what was done for enwiki (T354013) and plwiki (T362414), which only removed obsolete-tag but kept night-mode-unaware-background-color. (Minor note: the community discussion mentions it the other way around, but the current config in InitialiseSettings.php confirms this.) Based on the linked discussion, the community seems to have agreed on disallowing all lint errors without exceptions.

In T425651#11903320, @Samwilson wrote:

@HakanIST Does the nowrap fix above solve for your MR 77 changes as well?

Submitted fix: https://github.com/wikimedia/wikipedia-ios/pull/5842