The internal `Reader` class, instantiated inside every reader tab's iframe, creates a readiness promise in its constructor (https://github.com/zotero/reader/blob/d40161cd2ed3e353403040eedd1aaef8a9c5291f/src/common/reader.js#L131):

```js
this.initializedPromise = new Promise(
(resolve) => (this._resolveInitializedPromise = resolve),
);
```

Nothing ever calls that resolver on the `Reader` instance. The promise never resolves; any code that awaits `reader._internalReader.initializedPromise` silently hangs forever.

## Why it looks correct at a glance

The PDF view class declares an identically named `initializedPromise` that is wired correctly:

- Created: [src/pdf/pdf-view.js#L189](https://github.com/zotero/reader/blob/c6edbfff751952dcb4fbaf10dedf933493908832/src/pdf/pdf-view.js#L189)
- Resolved (preview path): [src/pdf/pdf-view.js#L245](https://github.com/zotero/reader/blob/c6edbfff751952dcb4fbaf10dedf933493908832/src/pdf/pdf-view.js#L245)
- Resolved (normal path, end of document init): [src/pdf/pdf-view.js#L465](https://github.com/zotero/reader/blob/c6edbfff751952dcb4fbaf10dedf933493908832/src/pdf/pdf-view.js#L465)

Zotero's own chrome code only ever awaits the view-level promise, never the Reader-level one. So core Zotero never hits the Reader-level hang; it's just misleading for plugin authors.

## Workaround

Await the primary view's promise instead (what Zotero core does):

```js
await reader._initPromise; // internal reader constructed
// (created https://github.com/zotero/zotero/blob/9.0.6/chrome/content/zotero/xpcom/reader.js#L57,
// resolved https://github.com/zotero/zotero/blob/9.0.6/chrome/content/zotero/xpcom/reader.js#L630)
await reader._internalReader._primaryView.initializedPromise; // view + document fully initialized
```

FYI https://github.com/zotero/reader/pull/171 is an open PR cleaning this footgun up.

Disclaimer: Fable 5 was used to help draft this issue.