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.
This commit is contained in:
parent
bf368f3a32
commit
0a4c326650
@ -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() {
|
||||
|
Loading…
Reference in New Issue
Block a user