Zotero reader: `Reader.initializedPromise` is never resolved
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.
```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.
-
dstillman Zotero TeamIf you think something has been missed, you can just post a follow-up on the PR. We try not to use the forums for technical discussions.
This discussion has been closed.
Upgrade Storage