Most recent bugs associated with the image when editing the Page namespace (e.g., T420077 and T421372) are caused by core changes in image thumbnailing instead of ProofreadPage itself. It could be true again this time.

The flickering is probably when OSD replaces the static thumbnail, and is expected.

Zooming (reset zoom button is a form of zooming) shows the image presumably because it forces OSD to render.

The question then is why doesn't it do so when it replaces the static image.

It could be MW/core thumbnail breakage, but that seems odd since zooming works based on the initial image data. More likely would be something like upstream OSD changing how to initialize the viewer (needs an extra call) or which event signals OSD is ready, or something like that. But in any case something triggered by the upgrade to OSD 6.0.2 (T422759) and presumably then necessitating tweaks to Proofread Page (or the Wikisource extension; not sure where the OSD support lives).

And 1269071 certainly looks suspicious. It both changes what kind of image source OSD is initialized with, but it also changes stuff in the OSD initialization code including dropping an async/await pair that very likely affects load order-dependant stuff, order of init events, etc.

The master branch of ProofreadPage works perfectly in my local environment, so I still think Wikisource is broken due to image thumbnails.

Proofreading is now not loading any image at all in the Proofread window. As of today, I am getting an error, but no image at all. Yesterday, the image flickered but was retrievable. Today it is not available at all. I get an error message "Failed to initialize OpenSeadragon; no image found"

In T423548#11830831, @EncycloPetey wrote:

Today it is not available at all. I get an error message "Failed to initialize OpenSeadragon; no image found"

Now that sounds more like a MW-core thumbnailing issue to me. That's OSD complaining that it can't find the image its been told to work on. You get that when, for example, Commons / Thumbor /Swift is down or returning 429 statuses. But I'm not seeing that from my end: if I zoom the image renders just fine.

I think I saw some patch hit this past week that could conceivably affect how thumbnails are replicated across datacenters, and myself and EncycloPetey are likely to get routed to different datacenters, so that might just possibly be worth checking. T328872 I think, and @Ladsgroup and @CDanis are the ones currently tinkering with it. But if anything is broken at that layer I would expect a lot more people to have noticed and reported it, so it doesn't seem all that likely.

What is interesting is that I manage to view and zoom in the image of https://en.wikisource.org/w/index.php?title=Page:Poems_by_Ellen_Russell_Emerson.djvu/69&action=edit without trouble, both logged in and as anonymous. Could it be a concurrency bug, maybe with custom js scripts?

Today, due to an incident, SRE accidentally blocked most of Chrome from accessing images (upload.wikimedia.org) which obviously is reverted now. Could it be the cause? it seems fixed to me and I can't reproduce the problem.

I can still reproduce the underlying problem of Openseadragon flickering, even in safemode. I haven't been able to reproduce the "Failed to initialize OpenSeadragon; no image found" message (also, that message typically means "ProofreadPage was not able to find any image associated with the current page and the frontend is running in circles"). I don't think either is due to the SRE incident (since moving the image around/triggering the OSD plane causes the image to pop back in, which would not have been possible if SRE hadn't sent the image in the first place).

I am seeing broken thumbnails on Wikidata now as well, such as: https://www.wikidata.org/wiki/Q249769 under the image property.

In T423548#11831171, @Ladsgroup wrote:

Today, due to an incident, SRE accidentally blocked most of Chrome from accessing images (upload.wikimedia.org) which obviously is reverted now. Could it be the cause? it seems fixed to me and I can't reproduce the problem.

I am not using Chrome. I am (and have been) using Firefox.

The thumbnail size is standard so it's not my work. It could be other rate limiting implemented by the traffic team. I tag them instead as they implemented those and know better to investigate.
https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/The_Murder_Of_Agamemnon_-_Project_Gutenberg_eText_14994.png/250px-The_Murder_Of_Agamemnon_-_Project_Gutenberg_eText_14994.png

This is clearly not my rate limit. Mine has a different error. See https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/The_Murder_Of_Agamemnon_-_Project_Gutenberg_eText_14994.png/251px-The_Murder_Of_Agamemnon_-_Project_Gutenberg_eText_14994.png for example (251px instead of 250px)

After clicking on the image, the image container tag changes as follows. https://ru.wikisource.org/w/index.php?title=Страница:Вопросы_жизни._1905._№12.djvu/22&action=edit Was:

<div class="openseadragon-canvas" tabindex="0" style="background: none transparent; border: none; margin: 0px; padding: 0px; position: absolute; width: 100%; height: 100%; overflow: hidden; top: 0px; left: 0px; touch-action: none; pointer-events: auto; text-align: left;">
<canvas width="883" height="664" style="background: none transparent; border: none; margin: 0px; padding: 0px; position: absolute; width: 100%; height: 100%; left: 0px; pointer-events: none; touch-action: none;"></canvas>
<div style="background: none transparent; border: none; margin: 0px; padding: 0px; position: static;"></div>
</div>

Now after click, with the image loading. You can see that a line is added below, almost identical to the one already there.

<div class="openseadragon-canvas" tabindex="0" style="background: none transparent; border: none; margin: 0px; padding: 0px; position: absolute; width: 100%; height: 100%; overflow: hidden; top: 0px; left: 0px; touch-action: none; pointer-events: auto; text-align: left;">
<canvas width="883" height="664" style="background: none transparent; border: none; margin: 0px; padding: 0px; position: absolute; width: 100%; height: 100%; left: 0px; pointer-events: none; touch-action: none;"></canvas>
<div style="background: none transparent; border: none; margin: 0px; padding: 0px; position: static;"></div>
<canvas width="883" height="664" style="background: none transparent;border: none;margin: 0px;padding: 0px;position: absolute;width: 100%;height: 100%;left: 0px;pointer-events: none;touch-action: none;visibility: hidden;"></canvas>
</div>

After loading, the image is displayed in the first <canvas> tag. The second tag can be disabled using the CSS property "display: none;" or removed.

I can still reproduce the original problem in latest Safari, Chrome, and Firefox on macOS (latest). Both logged in and in private browsing (logged out).

The JS console shows the error "Error creating texture in WebGL." emitted from openseadragon.js.

I see the same problem in both Firefox and Chrome on MacOS, logged in or logged out, including in safe mode (safemode=1). I don't see any JS console errors. The problem is consistent and always happens when I load the page editor.

This also happens in Firefox. It probably affects all Wikisources (I have checked English and Ukrainian)

Image doesn't get shown when you open the editing page. You need to interact with image for it to appear properly (moving page around with mouse, changing zoom level, rotating the image works).

Page on load

Page after interaction

Change #1275116 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/ProofreadPage@master] Update fallback URL for OpenSeadragonController.getCurrentImage

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

I thought perhaps this was related to how it's loading the rotation/zoom/pan in initializeViewportFromSavedData(), but the bug seems to happen regardless of whether there's any saved data.

Could this be similar to this OSD issue with cross-origin images? Which might explain why we're not able to reproduce this locally.

It might be sufficient to force a redraw after loading (patch above) but I'm not really sure.

Change #1275117 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/ProofreadPage@master] Force image redraw in OpenSeadragon 'open' event

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

I am not sure if it's the same error, but ever since this bug started (apparently 15/04/26) I'm also experiencing a bug with the EditInSequence extension, where every page shows the same image. Whenever I change pages this error appears in my console:

oojs.js:867 Uncaught TypeError: Cannot read properties of undefined (reading '0')
    at OpenseadragonController.js.OpenseadragonController.initializer (OpenseadragonController.js:30:31)
    at OO.EventEmitter.emit (oojs.js:858:12)
    at OpenSeadragonController.initialize (OpenseadragonController.js:82:7)
    at OpenSeadragonController.forceInitialize (OpenseadragonController.js:154:7)
    at OpenseadragonController.js.OpenseadragonController.update (OpenseadragonController.js:59:20)
    at OO.EventEmitter.emit (oojs.js:858:12)
    at PagelistModel.js.PagelistModel.next (PagelistModel.js:152:7)
    at PageNavTools.js.NextTool.onSelect (PageNavTools.js:92:33)
    at OO.ui.ToolGroup.onMouseKeyUp (oojs-ui-toolbars.js:1328:16)
    at OO.ui.ToolGroup.onDocumentMouseKeyUp (oojs-ui-toolbars.js:1309:7)

I find it hard to believe that the two extensions failed at the same time for unrelated reasons.

In T423548#11836558, @Ninovolador wrote:

I am not sure if it's the same error, but ever since this bug started (apparently 15/04/26) I'm also experiencing a bug with the EditInSequence extension, where every page shows the same image.

Could you provide a link so that we can reproduce the issue?

In T423548#11836507, @Samwilson wrote:

Could this be similar to this OSD issue with cross-origin images? Which might explain why we're not able to reproduce this locally.

Nice catch! If WebGL does not support CORS, should we enforce the old behavior using Canvas?

In T423548#11836560, @Bhsd wrote:

Could you provide a link so that we can reproduce the issue?

Of course, this is the book I'm working on.

In T423548#11836564, @Ninovolador wrote:

In T423548#11836560, @Bhsd wrote:

Could you provide a link so that we can reproduce the issue?

Of course, this is the book I'm working on.

Thanks! I can confirm this is a leftover of T421372 and will address it soon.

If WebGL does not support CORS, should we enforce the old behavior using Canvas?

That was my first thought, but the docs say that "the 'webgl' drawer can automatically fall back to canvas as needed, for example to draw images that do not have CORS headers set which makes them tainted and unavailable to webgl." Although I don't know about that "can fall back", it's not clear when it will fall back.

Change #1275116 merged by jenkins-bot:

[mediawiki/extensions/ProofreadPage@master] Update fallback URL for OpenSeadragonController.getCurrentImage

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

Change #1275117 merged by jenkins-bot:

[mediawiki/extensions/ProofreadPage@master] Use canvas rather than webgl for OpenSeadragon

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

@Samwilson Do we need to backport the fixes? There is no regular deployment this week.

Change #1275808 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/ProofreadPage@wmf/1.46.0-wmf.24] Use canvas rather than webgl for OpenSeadragon

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

Good point! I've scheduled it for tomorrow morning.

Change #1275808 merged by jenkins-bot:

[mediawiki/extensions/ProofreadPage@wmf/1.46.0-wmf.24] Use canvas rather than webgl for OpenSeadragon

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

Mentioned in SAL (#wikimedia-operations) [2026-04-22T07:14:35Z] <samwilson@deploy1003> Started scap sync-world: Backport for [[gerrit:1275808|Use canvas rather than webgl for OpenSeadragon (T423548)]]

Mentioned in SAL (#wikimedia-operations) [2026-04-22T07:16:17Z] <samwilson@deploy1003> samwilson: Backport for [[gerrit:1275808|Use canvas rather than webgl for OpenSeadragon (T423548)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-04-22T07:23:06Z] <samwilson@deploy1003> Finished scap sync-world: Backport for [[gerrit:1275808|Use canvas rather than webgl for OpenSeadragon (T423548)]] (duration: 08m 31s)

That's deployed, and it looks like the bug is gone! At least, in my tests on enwikisource.