Add a PDFViewerApplication.initializedPromise property to allow (easier) tracking of when the default viewer has been initialized
#11607
Conversation
…sier) tracking of when the default viewer has been initialized
This complements the existing `PDFViewerApplication.initialized` boolean property, and may be helpful for custom implementations of the default viewer. This will thus provide users of the default viewer an alternative to setting the preference to dispatch events to the DOM (and listen for the "localized" event), since they can instead use:
```javascript
document.addEventListener("webviewerloaded", function() {
PDFViewerApplication.initializedPromise.then(function() {
// The viewer has now been initialized.
})
});
```
Note that in order to avoid manually tracking the initialization state *twice*, this implementation purposely uses the `PromiseCapability` functionality to handle both `PDFViewerApplication.initialized` and `PDFViewerApplication.initializedPromise` internally.
Snuffleupagus
force-pushed
the
app-initializedPromise
branch
from
44a6e0c
to
44587f3
Compare
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/87325bd249d38b6/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/87325bd249d38b6/output.txt Total script time: 2.52 mins Published |
|
Perhaps a bit off-topic for this particular patch, but I'm wondering how we should document the availability of this (and other) features for third-party users. There are quite a few tips and tricks third-party implementers can use, but we don't really document them nor do we have examples for all of them. This is one of those things that can be really useful, but there should be a way to discover that it exists. Do you have ideas for this? I'm thinking a wiki page could suffice and we can update it incrementally. |
That seems like a fair point! As long as any documentation prominently features the standard "please don't use the viewer as-is"-disclaimer, then I suppose that more documentation cannot hurt. Furthermore, you'd probably also need to make it very clear that while the general PDF.js library is versioned and shouldn't simply break in backwards incompatible ways (the latter probably applies to some extent to the "viewer components" too), the default viewer itself shouldn't be considered completely stable and things may change/break as required for e.g. Firefox's needs.
That sounds like the easiest solution, and shouldn't be too much effort to keep up-to-date. |
|
Nice improvement! I have made https://github.com/mozilla/pdf.js/wiki/Third-party-viewer-usage to track tips and tricks for custom viewer deployments. If you have additions, feel free to let me know and we can update the page. |
- Remove the `eventBusDispatchToDOM` option, as the client now watches for these events on the event bus. See [1]. - Use `PDFViewerApplication.initializedPromise` to simplify waiting for app to load. This was added in PDF.js v2.10.377. See [2]. [1] hypothesis/client#2641 [2] mozilla/pdf.js#11607
- Remove the `eventBusDispatchToDOM` option, as the client now watches for these events on the event bus. See [1]. - Use `PDFViewerApplication.initializedPromise` to simplify waiting for app to load. This was added in PDF.js v2.10.377. See [2]. [1] hypothesis/client#2641 [2] mozilla/pdf.js#11607
This complements the existing
PDFViewerApplication.initializedboolean property, and may be helpful for custom implementations of the default viewer. This will thus provide users of the default viewer an alternative to setting the preference to dispatch events to the DOM (and listen for the "localized" event), since they can instead use:Note that in order to avoid manually tracking the initialization state twice, this implementation purposely uses the
PromiseCapabilityfunctionality to handle bothPDFViewerApplication.initializedandPDFViewerApplication.initializedPromiseinternally.