From 0a4c3266501cf7b2340130d6567e48ed70df3fef Mon Sep 17 00:00:00 2001 From: Jonas Jenwald Date: Tue, 11 Sep 2018 14:34:20 +0200 Subject: [PATCH] Ensure that `PDFFindController._requestMatchesCount` won't return broken data when searching starts (PR 10052 follow-up) This is an unfortunate oversight on my part, which I stumbled upon when (locally) testing the `mozilla-central` follow-up patch necessary to enable the matches counter in the built-in PDF viewer. --- web/pdf_find_controller.js | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/web/pdf_find_controller.js b/web/pdf_find_controller.js index 2f5e919114109..e23068601f728 100644 --- a/web/pdf_find_controller.js +++ b/web/pdf_find_controller.js @@ -510,14 +510,20 @@ class PDFFindController { _requestMatchesCount() { const { pageIdx, matchIdx, } = this.selected; - let current = 0; + let current = 0, total = this.matchesCountTotal; if (matchIdx !== -1) { for (let i = 0; i < pageIdx; i++) { current += (this.pageMatches[i] && this.pageMatches[i].length) || 0; } current += matchIdx + 1; } - return { current, total: this.matchesCountTotal, }; + // When searching starts, this method may be called before the `pageMatches` + // have been counted (in `_calculateMatch`). Ensure that the UI won't show + // temporarily broken state when the active find result doesn't make sense. + if (current > total) { + current = total = 0; + } + return { current, total, }; } _updateUIResultsCount() {