On certain DjVu files, the following exception is thrown:
TypeError: success is not a function. (In 'success()', 'success' is an instance of Object)
The call stack in normal mode only contains ensureImageZoomInitialization, and in debug mode I've been unable to reproduce. However something is clearly failing (silently) in debug mode too, because the "Proofread tools" in the editor toolbar don't show up (they do in normal mode).
The user-visible effect of this is that the hidden text layer in the DjVu file is not loaded, I presume because the scripts that extract it bomb on this exception before getting to that point.
On files affected by this I get the symptom (no OCR text) consistently, but the console message does not always show up (something timing-dependent there?). For example this page.
The above example file has a known provenance (I generated it myself from raw scans) and examining it with the DjVuLibre command-line tools reveals nothing obviously out of the ordinary (i.e. this is not just T219376).
A few pages have pathological output: a hundred or so distinct regions containing a single space character. In the djvutxt dump output that retrieveMetaData() in DjVuImage.php works on, these will each show up as \n\037\013; and since retrieveMetaData() does a simple regex replace (cf. T230415) it is conceivable that the extremely long runs of this sequence will blow past a recursion, stack, or runtime limit in the regex engine or some similar weirdness.
Another possible trigger is the scan resolution. All the files I've seen it on are high-resolution (like 2–3k x 3–4k pixels), with each page in the 1MB range and the whole DjVu file in the 100MB to several hundred MB range. Since the call stack for the exception looks like image zooming code—and refers to a on-success function object that contains an object (error object that was not checked at the time it was first returned?) reference instead of a function reference—it is conceivable that large resolution or file size plays a role.
In any case, the first step here is probably for someone familiar with ensureImageZoomInitialization and its calling context to trace back where that success variable comes from and what might cause it to contain object instead of function.