With these changes `0`, `NaN`, `null`, and `undefined` in the `total`-property all result in `percent === NaN` being reported by the callback, since previously e.g. `0` would result in `percent === 100` being reported unconditionally which doesn't make a lot of sense.
Also, remove the "indeterminate" loadingBar (in the viewer) if the `PDFDocumentLoadingTask` fails since there won't be any more data arriving and displaying the animation thus seems wrong.
The original issue can only be reproduce when the thumbnails are on two lines.
The fix is just a matter of computing the number of elements on the last line once we've
finished the first line.
The user has to select some pages and then click on the "Save As" menu item in the Manage menu.
If they modify the structure of the pdf (deleted, moved, copied pages), they have to use the usual
save button.
Working on PR 20784, I couldn't help noticing that this code can be improved a little bit.
- Only initialize `PdfTextExtractor` in development mode and MOZCENTRAL builds, since it's unused elsewhere.
- Re-factor how `PdfTextExtractor` waits for the viewer to be available/ready, by using existing (internal) events.
This simplifies the `PdfTextExtractor` class and removes its `setViewer` method, which improves general consistency since normally the viewer-components don't use such a method in that way (here it was effectively used as a stand-in for a `setDocument` method).
- Finally, while slightly unrelated, rename the `#getAllTextInProgress` field in the `PDFViewer` class to `#copyAllInProgress` to clearly indicate what it's for since the `getAllText` method is used more generally now.
Given that extracting all text can take a while to complete, especially in long PDF documents[1], it's technically possible for the user to "select all", copy, and finally abort copying (with the `Esc` key) while `PdfTextExtractor.prototype.extractTextContent` is still running.
If that happens the `PDFViewer.prototype.getAllText` code would be interrupted, and text-extraction would thus fail in an intermittent and (likely) hard to debug way. To avoid this we replace the current "global" interrupt handling with an optional `AbortSignal` instead.
---
[1] See e.g. `pdf.pdf` in the test-suite.
Hopefully I'm not misunderstanding why it was written like that, however using an existing method should be a tiny bit more efficient than querying the DOM.
Clicking on the "Find Current Outline Item" button is (obviously) supposed to scroll that outline item into view, however that seems to have broken accidentally in PR 20495.
Change all these cases to use `Map.prototype.getOrInsertComputed()` instead, in combination with a helper function for creating the `Array`s (similar to the previous patch).
With the exception of the first invocation the callback function is unused, which means that a lot of pointless functions may be created.
To avoid this we introduce helper functions for simple cases, such as creating `Map`s and `Objects`s.
