Sakurai/pdf.js
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[PDFHistory] Correctly simulate an internal destination in the pushPage-method (PR 12493 follow-up)

Browse Source 
The intention, in PR 12493, was that the page we're adding to the browser history should behave as if it were a "regular" internal destination (to properly convey user intent).
Unfortunately, since I didn't consider all the edge-cases correctly, it ended up behaving like a URL-hash instead which obviously wasn't intended. Note that currently this isn't a problem, however it can become an issue (in some cases) with upcoming re-factoring around `PDFHistory` and OpenAction support[1].

---
[1] I've started working on fixing the following TODO, which will require a couple of smaller tweaks here and there: 9d0ce6e79f/web/app.js (L1680-L1681)
This commit is contained in:
Jonas Jenwald 2021-03-24 22:07:29 +01:00
parent 685a60055e
commit a10f87c7ea
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
web/pdf_history.js
View File

@ -292,6 +292,8 @@ class PDFHistory {
}
this._pushOrReplaceState({
// Simulate an internal destination, for `this._tryPushCurrentPosition`:
dest: null,
hash: `page=${pageNumber}`,
page: pageNumber,
rotation: this.linkService.rotation,
@ -458,7 +460,7 @@ class PDFHistory {
// - contains an internal destination, since in this case we
// cannot ensure that the document position has actually changed.
// - was set through the user changing the hash of the document.
if (this._destination.dest || !this._destination.first) {
if (this._destination.dest !== undefined || !this._destination.first) {
return;
}
// To avoid "flooding" the browser history, replace the current entry.