From 0a4c3266501cf7b2340130d6567e48ed70df3fef Mon Sep 17 00:00:00 2001
From: Jonas Jenwald <jonas.jenwald@gmail.com>
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 2f5e91911..e23068601 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() {