Feature add - Find match count (issue #4805)

[andyparisi]

Hi all!

This is my first contribution to the project (and first time looking at this codebase)–so I apologize ahead of time if I have missed anything obvious. What I've done here is try to implement a simple match count for the find bar.

Please let me know if there's something I have misplaced or just done wrong. I'm open to feedback and look forward to contributing more to this project.

[timvandermeij]

@andyparisi First of all, welcome to the project and thank you for your contribution! I have added some review comments to improve the code. After you have addressed those, could you squash your commits into one? See https://github.com/mozilla/pdf.js/wiki/Squashing-Commits on how to do that easily. That is important to make review easier and to keep the Git history clean.

[timvandermeij]

Just adding that this fixes #4805.

[Snuffleupagus]

Just adding that this fixes #4805.

This only addresses the issue for the generic viewer, but not for the firefox/mozcentral ones (since those use the find UI in the browser). However, that is probably best to handle in a follow-up patch.
I'm also tagging this PR as "1-ux", since the UI aspect of this feature might need some tweaking.

[andyparisi]

Thanks for the comments everyone. I've implemented your edits and successfully squashed them into a single commit. (Still don't entirely understand how squashing works, but the instructions were good).

[timvandermeij]

@andyparisi Nice work! We will review this again later, but this is looking good.

Squashing commits basically means that you merge the changes of multiple commits into one. Say you have three commits:

1. Implemented password dialog
2. Fixed password dialog to disallow empty input
3. Fixed button alignment issue in password dialog

In order to assist reviewing (reviewing one commit is easier than three commits) and to keep the Git history clean (i.e. https://github.com/mozilla/pdf.js/commits/master, so we can easily track down where a feature was merged), squashing commits happens often. In the case above, commits 2 and 3 are really just fixes for the first commit, so what those squash commands do is merge in those changes in the first commit. How it exactly works is essentially how git merge works.

I hope this makes it a bit more clear for you.

[andyparisi]

Thanks Tim. That helps a lot. Just need to get a better hang of git to really get it all. I'm trying to move away from GUI apps slightly to learn the command line stuff.

[Snuffleupagus]

To make this perform better, we should probably do what the native find bar does in Firefox and stop counting matches above some reasonable threshold. In Firefox, the default value is 100.

[yurydelendik]

(https://bugzilla.mozilla.org/show_bug.cgi?id=1062025)

[heavensrevenge]

Any progress on this? I'm glad there has been others interested in a such a simple but extremely useful piece of information about a document.

[Inversion-des]

Applied this patch manually for some older version.
Works for me. Thank you!

[brendandahl]

@andyparisi Could you rebase your branch I think this is good to go.

To make this perform better, we should probably do what the native find bar does in Firefox and stop counting matches above some reasonable threshold. In Firefox, the default value is 100.

The calculation of the number of matches shouldn't be an issue here, but yes we should probably limit matches somewhere else in the code. This can be in a different PR though.

[yurydelendik]

Merged by c2e70ea

Thank you for the patch