Re-factor the isPageVisible-handling in the find-controller (PR 10217 follow-up)

The way that this was implemented in PR 10217 has always bothered me slightly, since the `isPageVisible`-method that I introduced there always felt quite out-of-place in the `IPDFLinkService`-implementations.
Hence this is instead replaced by a callback-function in `PDFFindController`, to handle the page-visibility checks. Note that since the `PDFViewer`-constructor always sets this callback-function, e.g. the viewer-component examples still work as-is.
This commit is contained in:
Jonas Jenwald 2023-05-26 10:31:54 +02:00
parent cbc4b20b12
commit d0bf505312
4 changed files with 14 additions and 45 deletions

View file

@ -396,6 +396,12 @@ class PDFFindController {
this._eventBus = eventBus;
this.#updateMatchesCountOnProgress = updateMatchesCountOnProgress;
/**
* Callback used to check if a `pageNumber` is currently visible.
* @type {function}
*/
this.onIsPageVisible = null;
this.#reset();
eventBus._on("find", this.#onFind.bind(this));
eventBus._on("findbarclose", this.#onFindBarClose.bind(this));
@ -636,15 +642,12 @@ class PDFFindController {
// there's a risk that consecutive 'findagain' operations could "skip"
// over matches at the top/bottom of pages thus making them completely
// inaccessible when there's multiple pages visible in the viewer.
if (
return (
pageNumber >= 1 &&
pageNumber <= linkService.pagesCount &&
pageNumber !== linkService.page &&
!linkService.isPageVisible(pageNumber)
) {
return true;
}
return false;
!(this.onIsPageVisible?.(pageNumber) ?? true)
);
case "highlightallchange":
return false;
}