Add a reset method to the PDFHistory implementation
#11380
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Snuffleupagus
force-pushed
the
PDFHistory-reset
branch
from
cbfe3c1 to
fef0cbb
Compare
Snuffleupagus
force-pushed
the
PDFHistory-reset
branch
2 times, most recently
from
ca7f8d0 to
c65c2e2
Compare
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/f2832fc89f01d0e/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/f2832fc89f01d0e/output.txt Total script time: 1.72 mins Published |
This patch addresses a couple of smaller issues with the `PDFHistory` class: - Most, if not all, other viewer components can be reset in one way or another, and there's no good reason for the `PDFHistory` implementation to be different here. - Currently it's (technically) possible to keep adding entries to the browser history, via the `PDFHistory` instance, even after the document has been closed. That obviously makes no sense, and is caused by the lack of a `reset` method. - The internal `this._isPagesLoaded` property was never actually reset, which would lead to it being temporarily wrong when a new document was opened in the default viewer.
Looking at the `parseCurrentHash` function again it's now difficult for me to understand *what* I was thinking, since having a helper function that needs to be manually passed a `linkService` reference just looks weird.
…ate`, for e.g. MOZCENTRAL builds By re-ordering the condition, which includes a `PDFJSDev` check, we can avoid meaningless output in the built files.
Snuffleupagus
force-pushed
the
PDFHistory-reset
branch
from
c65c2e2 to
1fab637
Compare
|
Nice work! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch addresses a couple of smaller issues with the
PDFHistoryclass:Most, if not all, other viewer components can be reset in one way or another, and there's no good reason for the
PDFHistoryimplementation to be different here.Currently it's (technically) possible to keep adding entries to the browser history, via the
PDFHistoryinstance, even after the document has been closed. That obviously makes no sense, and is caused by the lack of aresetmethod.The internal
this._isPagesLoadedproperty was never actually reset, which would lead to it being temporarily wrong when a new document was opened in the default viewer.