2018-09-22 05:40:15 +09:00
|
|
|
/* Copyright 2018 Mozilla Foundation
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
import { buildGetDocumentParams } from './test_utils';
|
|
|
|
import { EventBus } from '../../web/ui_utils';
|
|
|
|
import { getDocument } from '../../src/display/api';
|
|
|
|
import { PDFFindController } from '../../web/pdf_find_controller';
|
|
|
|
import { SimpleLinkService } from '../../web/pdf_link_service';
|
|
|
|
|
|
|
|
class MockLinkService extends SimpleLinkService {
|
|
|
|
constructor() {
|
|
|
|
super();
|
|
|
|
|
|
|
|
this._page = 1;
|
|
|
|
this._pdfDocument = null;
|
|
|
|
}
|
|
|
|
|
|
|
|
setDocument(pdfDocument) {
|
|
|
|
this._pdfDocument = pdfDocument;
|
|
|
|
}
|
|
|
|
|
|
|
|
get pagesCount() {
|
|
|
|
return this._pdfDocument.numPages;
|
|
|
|
}
|
|
|
|
|
|
|
|
get page() {
|
|
|
|
return this._page;
|
|
|
|
}
|
|
|
|
|
|
|
|
set page(value) {
|
|
|
|
this._page = value;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
describe('pdf_find_controller', function() {
|
|
|
|
let eventBus;
|
|
|
|
let pdfFindController;
|
|
|
|
|
|
|
|
beforeEach(function(done) {
|
|
|
|
const loadingTask = getDocument(buildGetDocumentParams('tracemonkey.pdf'));
|
|
|
|
loadingTask.promise.then(function(pdfDocument) {
|
Make `PDFFindController` less confusing to use, by allowing searching to start when `setDocument` is called
*This patch is based on something that I noticed while working on PR 10126.*
The recent re-factoring of `PDFFindController` brought many improvements, among those the fact that access to `BaseViewer` is no longer required. However, with these changes there's one thing which now strikes me as not particularly user-friendly[1]: The fact that in order for searching to actually work, `PDFFindController.setDocument` must be called *and* a 'pagesinit' event must be dispatched (from somewhere).
For all other viewer components, calling the `setDocument` method[2] is enough in order for the component to actually be usable.
The `PDFFindController` thus stands out quite a bit, and it also becomes difficult to work with in any sort of custom implementation. For example: Imagine someone trying to use `PDFFindController` separately from the viewer[3], which *should* now be relatively simple given the re-factoring, and thus having to (somehow) figure out that they'll also need to manually dispatch a 'pagesinit' event for searching to work.
Note that the above even affects the unit-tests, where an out-of-place 'pagesinit' event is being used.
To attempt to address these problems, I'm thus suggesting that *only* `setDocument` should be used to indicate that searching may start. For the default viewer and/or the viewer components, `BaseViewer.setDocument` will now call `PDFFindController.setDocument` when the document is ready, thus requiring no outside configuration anymore[4]. For custom implementation, and the unit-tests, it's now as simple as just calling `PDFFindController.setDocument` to allow searching to start.
---
[1] I should have caught this during review of PR 10099, but unfortunately it's sometimes not until you actually work with the code in question that things like these become clear.
[2] Assuming, obviously, that the viewer component in question actually implements such a method :-)
[3] There's even a very recent issue, filed by someone trying to do just that.
[4] Short of providing a `PDFFindController` instance when creating a `BaseViewer` instance, of course.
2018-10-03 19:42:41 +09:00
|
|
|
eventBus = new EventBus();
|
|
|
|
|
2018-09-22 05:40:15 +09:00
|
|
|
const linkService = new MockLinkService();
|
|
|
|
linkService.setDocument(pdfDocument);
|
|
|
|
|
|
|
|
pdfFindController = new PDFFindController({
|
|
|
|
linkService,
|
|
|
|
eventBus,
|
|
|
|
});
|
Make `PDFFindController` less confusing to use, by allowing searching to start when `setDocument` is called
*This patch is based on something that I noticed while working on PR 10126.*
The recent re-factoring of `PDFFindController` brought many improvements, among those the fact that access to `BaseViewer` is no longer required. However, with these changes there's one thing which now strikes me as not particularly user-friendly[1]: The fact that in order for searching to actually work, `PDFFindController.setDocument` must be called *and* a 'pagesinit' event must be dispatched (from somewhere).
For all other viewer components, calling the `setDocument` method[2] is enough in order for the component to actually be usable.
The `PDFFindController` thus stands out quite a bit, and it also becomes difficult to work with in any sort of custom implementation. For example: Imagine someone trying to use `PDFFindController` separately from the viewer[3], which *should* now be relatively simple given the re-factoring, and thus having to (somehow) figure out that they'll also need to manually dispatch a 'pagesinit' event for searching to work.
Note that the above even affects the unit-tests, where an out-of-place 'pagesinit' event is being used.
To attempt to address these problems, I'm thus suggesting that *only* `setDocument` should be used to indicate that searching may start. For the default viewer and/or the viewer components, `BaseViewer.setDocument` will now call `PDFFindController.setDocument` when the document is ready, thus requiring no outside configuration anymore[4]. For custom implementation, and the unit-tests, it's now as simple as just calling `PDFFindController.setDocument` to allow searching to start.
---
[1] I should have caught this during review of PR 10099, but unfortunately it's sometimes not until you actually work with the code in question that things like these become clear.
[2] Assuming, obviously, that the viewer component in question actually implements such a method :-)
[3] There's even a very recent issue, filed by someone trying to do just that.
[4] Short of providing a `PDFFindController` instance when creating a `BaseViewer` instance, of course.
2018-10-03 19:42:41 +09:00
|
|
|
pdfFindController.setDocument(pdfDocument); // Enable searching.
|
2018-09-22 05:40:15 +09:00
|
|
|
|
|
|
|
done();
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
afterEach(function() {
|
|
|
|
eventBus = null;
|
|
|
|
pdfFindController = null;
|
|
|
|
});
|
|
|
|
|
|
|
|
it('performs a basic search', function(done) {
|
|
|
|
pdfFindController.executeCommand('find', { query: 'Dynamic', });
|
|
|
|
|
|
|
|
const matchesPerPage = [11, 5, 0, 3, 0, 0, 0, 1, 1, 1, 0, 3, 4, 4];
|
|
|
|
const totalPages = matchesPerPage.length;
|
|
|
|
const totalMatches = matchesPerPage.reduce((a, b) => {
|
|
|
|
return a + b;
|
|
|
|
});
|
|
|
|
|
|
|
|
eventBus.on('updatefindmatchescount',
|
|
|
|
function onUpdateFindMatchesCount(evt) {
|
|
|
|
if (pdfFindController.pageMatches.length !== totalPages) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
eventBus.off('updatefindmatchescount', onUpdateFindMatchesCount);
|
|
|
|
|
|
|
|
expect(evt.matchesCount.total).toBe(totalMatches);
|
|
|
|
for (let i = 0; i < totalPages; i++) {
|
|
|
|
expect(pdfFindController.pageMatches[i].length)
|
|
|
|
.toEqual(matchesPerPage[i]);
|
|
|
|
}
|
|
|
|
done();
|
|
|
|
});
|
|
|
|
});
|
|
|
|
});
|