Commit Graph

77 Commits

Author SHA1 Message Date
Jonas Jenwald
4ab4efd42f Change the parseQueryString function to return a Map rather than an Object (issue 13829)
Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data).

Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object).

This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me).
Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-07-31 23:24:49 +02:00
Jonas Jenwald
a10f87c7ea [PDFHistory] Correctly simulate an internal destination in the pushPage-method (PR 12493 follow-up)
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)
2021-03-25 12:24:28 +01:00
Jonas Jenwald
685a60055e [PDFHistory] Reduce unnecessary duplication, by introducing a helper-method for validating pageNumbers 2021-03-24 22:01:53 +01:00
Ikko Ashimine
0de15d59b8
Fix typo in pdf_history.js
occuring -> occurring
2021-03-24 23:18:40 +09:00
Jonas Jenwald
81525fd446 Use ESLint to ensure that exports are sorted alphabetically
There's built-in ESLint rule, see `sort-imports`, to ensure that all `import`-statements are sorted alphabetically, since that often helps with readability.
Unfortunately there's no corresponding rule to sort `export`-statements alphabetically, however there's an ESLint plugin which does this; please see https://www.npmjs.com/package/eslint-plugin-sort-exports

The only downside here is that it's not automatically fixable, but the re-ordering is a one-time "cost" and the plugin will help maintain a *consistent* ordering of `export`-statements in the future.
*Note:* To reduce the possibility of introducing any errors here, the re-ordering was done by simply selecting the relevant lines and then using the built-in sort-functionality of my editor.
2021-01-09 20:37:51 +01:00
Jonas Jenwald
739d7c6d77 Support the once option, when registering EventBus listeners
This follows the same principle as the `once` option that exists in the native `addEventListener` method, and will thus automatically remove an `EventBus` listener when it's invoked; see https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#Parameters

Finally, this patch also tweaks some the existing `EventBus`-code to use modern features such as optional chaining and logical assignment operators.
2020-12-29 16:49:13 +01:00
Jonas Jenwald
c185061757 Include the state in the "presentationmodechanged" event, and remove the separate active/switchInProgress properties
Given that we already have a `PresentationModeState`-enumeration, we should use that with the "presentationmodechanged" event rather than including separate properties. Note that this new behaviour, of including an enumeration-value in the event, is consistent with lots of other existing viewer-events.

To hopefully avoid issues in custom implementations of the default viewer, any attempt to access the removed properties will now throw.
2020-12-28 20:31:17 +01:00
Jonas Jenwald
322b1072af Use optional chaining in web/pdf_history.js
Since we're now free to use e.g. optional chaining everywhere *except* for the worker, we can thus simplify this code a bit.
2020-11-02 11:36:17 +01:00
Jonas Jenwald
b302fd3a6e Move updating of this._maxUid into PDFHistory._updateInternalState
There's no compelling reason to update this property *manually* in multiple places, since that's error-prone with any future code changes, given that `_updateInternalState` is always called just before anyway.
2020-10-18 16:29:15 +02:00
Jonas Jenwald
295716f496 Support adding pages, in addition to regular destinations, to the browser history and use it with thumbnails (issue 12440)
While the referenced issue could very well be seen as an edge-case, this patch adds support for updating of the browser history when interacting with the thumbnails in the sidebar (assuming we want to do this).

The main reason for adding the history implementation in the first place, was to simplify navigating back to a previous position in the document when named/explicit destinations are used (e.g. when clicking on "links" or when using the outline in the sidebar).
As such, it never really crossed by mind to update the browser history when the thumbnails are used. However, a user clicking on thumbnails could be regarded as a pretty strong indication of user-intent w.r.t. navigation in the document, hence I suppose that updating the browser history in this particular case probably won't hurt.
2020-10-18 16:04:00 +02:00
Jonas Jenwald
8431cfe482 Re-name and re-factor the PDFLinkService.navigateTo method
This modernizes and improves the code, by using `async`/`await` and by extracting the helper function to its own method.
To hopefully avoid confusion, given the next patch, the method is also re-named to `goToDestination` to make is slightly clearer what it actually does.
2020-10-18 14:29:59 +02:00
Jonas Jenwald
af1bb04662 Attempt to respect the "zoom" hash parameter, even when the "nameddest" parameter is present (issue 11875)
Given that the `PDFLinkService.setHash` method itself if completely synchronous, moving the handling of "nameddest" to occur last *shouldn't* cause any problems (famous last words).
This way the destination will still override any previous parameter, such as e.g. the "page", as expected. Furthermore, given that the `PDFLinkService.navigateTo` method is asynchronous that should provide additional guarantees that the "nameddest" parameter is always respected.

As sort-of expected, this fairly innocent looking change also required some tweaks in the `PDFHistory` to prevent dummy history entires upon document load (only an issue when both "page" *and* "nameddest" parameters are provided in the hash).
2020-05-07 13:53:07 +02:00
Jonas Jenwald
7fd5f2dd61 [api-minor] Remove the getGlobalEventBus viewer functionality (PR 11631 follow-up)
The correct/intended way of working with the "viewer components" is by providing an `EventBus` instance upon initialization, and the `getGlobalEventBus` was only added for backwards compatibility.
Note, for example, that using `getGlobalEventBus` doesn't really work at all well with a use-case where there's *multiple* `PDFViewer` instances on a one page, since it may then be difficult/impossible to tell which viewer a particular event originated from.

All of the "viewer components" examples have been previously updated, such that there's no longer any code/examples which relies on the now removed `getGlobalEventBus` functionality.
2020-03-29 12:20:23 +02:00
Jonas Jenwald
4a1b056c82 Re-factor the EventBus to allow servicing of "external" event listeners *after* the viewer components have updated
Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples:
The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first.
However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact.

Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page).

---
[1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes).
In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference.

[2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 19:38:13 +01:00
Jonas Jenwald
36881e3770 Ensure that all import and require statements, in the entire code-base, have a .js file extension
In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-04 13:01:43 +01:00
Jonas Jenwald
5d14e68bec Enable the ESLint prefer-const rule in the web/ directory
Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const

Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 01:03:58 +01:00
Jonas Jenwald
a63f7ad486 Fix the linting errors, from the Prettier auto-formatting, that ESLint --fix couldn't handle
This patch makes the follow changes:
 - Remove no longer necessary inline `// eslint-disable-...` comments.
 - Fix `// eslint-disable-...` comments that Prettier moved down, thus causing new linting errors.
 - Concatenate strings which now fit on just one line.
 - Fix comments that are now too long.
 - Finally, and most importantly, adjust comments that Prettier moved down, since the new positions often is confusing or outright wrong.
2019-12-26 12:35:12 +01:00
Jonas Jenwald
de36b2aaba Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).

Prettier is being used for a couple of reasons:

 - To be consistent with `mozilla-central`, where Prettier is already in use across the tree.

 - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.

Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.

*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.

(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-26 12:34:24 +01:00
Jonas Jenwald
1fab637247 Prevent if (!state || false) { in the output, in PDFHistory._popState, for e.g. MOZCENTRAL builds
By re-ordering the condition, which includes a `PDFJSDev` check, we can avoid meaningless output in the built files.
2019-12-13 10:38:39 +01:00
Jonas Jenwald
c5f2f870cb Move the parseCurrentHash helper function into PDFHistory
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.
2019-12-13 10:38:39 +01:00
Jonas Jenwald
d621899d50 Add a reset method to the PDFHistory implementation
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.
2019-12-13 10:38:39 +01:00
Jonas Jenwald
878432784c [PDFHistory] Move the IE11 pushState/replaceState work-around to src/shared/compatibility.js (PR 10461 follow-up)
I've always disliked the solution in PR 10461, since it required changes to the `PDFHistory` code itself to deal with a bug in IE11.
Now that IE11 support is limited, it seems reasonable to remove these `pushState`/`replaceState` hacks from the main code-base and simply use polyfills instead.
2019-11-11 17:48:04 +01:00
Tim van der Meij
8b4ae6f3eb
Consistently use @type for getter data types in JSDoc comments
Sometimes we also used `@return` or `@returns`, but `@type` is what
the JSDoc documentation recommends. This also improves the documentation
because before this commit the types were not shown and now they are.
2019-10-13 13:58:17 +02:00
Tim van der Meij
f4daafc077
Consistently use square brackets for optional parameters in JSDoc comments
Square brackets are recommended to indicate optional parameters. Using
them helps for automatically generating correct documentation.
2019-10-13 13:58:17 +02:00
Jonas Jenwald
ffe798137f Avoid setting incorrect document URLs, in IE 11, when the browser history is updated (PR 10423 follow-up)
Apparently in IE 11 when `history.{pushState, replaceState}` is called, there's actually a difference between not providing the *third* argument vs providing it set implicitly to `undefined`. It appears that in IE 11 it's actually being stringified, rather than ignored, which seems completely wrong (obviously other browsers aren't affected, so no surprises there).

This is yet another reason why I think the feature itself was a really bad idea, since it now requires extra/duplicated code just to prevent weird/incorrect URL behaviour in crappy browsers.
2019-01-16 19:26:44 +01:00
Jonas Jenwald
4773bf6fcb Add support for updating the document hash, off by default, when the browser history is updated (issue 5753)
This is *really* the best that we can do here, since other proposed solutions would interfere with (and break) the painstakingly implemented browsing history that's present in the default viewer.

I'm still not convinced that this is a good idea in general, but this patch implements it in a way where it is possible to toggle[1] for users that wish to have this feature. In particular, there's a couple of reasons why I'm not finding this feature necessary/great:
 - It's already possible to easily obtain the current hash, by simply clicking on the `viewBookmark` button at any time.
 - Hash changes requires a bit of special handling[2], i.e. extra code, to prevent issues when the browser history is traversed (see `PDFHistory._popState`). Currently this is only necessary when the user has manually changed the hash, with this patch it will always be the case (assuming the feature is active).
 - It's not always possible to change the URL when updating the browser history. For example: In the Firefox built-in viewer, the URL cannot be modified for local files (i.e. those using the `file://` protocol).
This leads to inconsistent behaviour, and may in some cases even result in errors being thrown and the history thus not updating, if the browser prevents changes to the URL during `pushState`/`replaceState` calls.

---
[1] Using the `historyUpdateUrl` viewer preference.

[2] This depends, to a great extent, on browsers always firing `popstate` events *before* `hashchange` events, which may or may not actually be guaranteed.
2019-01-06 20:09:02 +01:00
Jonas Jenwald
d46715210a Accept non-matching document fingerprints, in PDFHistory, when the viewer is reloaded (issue 6847)
This should hopefully be sufficient to address issue 6847, and given the limited impact of the code changes I'm not completely sure if this would need to be controlled by a preference!?

Initially my intention was to try and provide some (slightly more detailed) implementation suggestions in the issue, but having looked briefly at doing that it would essentially have amounted to actually writing the code anyway. (Especially considering that the recent questions seemed to more-or-less ignore the information already provided in the first post.)

Finally, note that since `performance.navigation.type` is marked as deprecated, a slightly different approach was choosen instead.
2019-01-06 17:02:39 +01:00
Jonas Jenwald
a7e70a50f5 Add OpenAction destination support, off by default, to the viewer
Given that it's really not clear to me if this is actually desired functionality in the default viewer, and considering that it doesn't fit in *great* with the way that `PDFHistory` is initialized, this feature is currently off by default[1].

---
[1] It's controlled with the `disableOpenActionDestination` Preference/AppOption.
2018-12-19 11:45:17 +01:00
Jonas Jenwald
89e479dd6c Tweak the PDFHistory._tryPushCurrentPosition method to work better with the different Scroll/Spread viewer modes
Given that a larger number of pages may now be visible at once, and importantly that their layout may be non-vertical, one of the conditions should be tweaked to not accidentally miss cases where a page is still visible.

Please note: This patch is based on code-inspection, and the only ill effect occurring without it would be a couple of (near) duplicate history entries in some *rare* edge-cases.
2018-12-07 15:06:58 +01:00
Jonas Jenwald
e2e9657ed0 Remove the attachDOMEventsToEventBus functionality, since EventBus instances are able to re-dispatch events to the DOM (PR 10019, bug 1492849 follow-up)
This also removes the old 'pagechange'/'scalechange'/'documentload' events.
2018-10-31 23:32:39 +01:00
Jonas Jenwald
61186698c3 Replace the remaining occurences of instanceof Array with Array.isArray()
*Follow-up to PRs 8864 and 8813.*

As explained in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray, `instanceof Array` can have inconsistent behavior. To ensure that only `Array.isArray` is used, an ESLint plugin/rule is added to enforce this.
2018-07-09 13:17:41 +02:00
Jonas Jenwald
3c622ef048 Replace the cloneObj helper function, in the viewer, with native Object.assign (PR 9795 follow-up) 2018-06-27 20:39:39 +02:00
Rob Wu
e904b8a67c Drop third parameter to replaceState/pushState
This was introduced in #3582 to work around https://crbug.com/274024 .
The bug in Chrome has been fixed a long time ago (at least 33), so let's
simplify the code.
2018-01-26 13:23:51 +01:00
Jonas Jenwald
e20eacd484 Allow overwriting temporary, in addition to empty, history entries on 'pagehide'
When navigating away from the viewer, there's no good reason for disallowing replacement of a *temporary* history entry (in addition to empty ones).

Given that the current position is temporarily added to the browser history using a (short) timeout, the history entry will most likely already be correct when the 'pagehide' event fires. However, if the user is quick enough that might not always be the case, in which case the adjusted logic may help.
2018-01-11 12:34:19 +01:00
Jonas Jenwald
448a7a27cb Ensure that the PDFHistory._maxUid property is correctly updated when initializing/navigating the history
This is a follow-up to commit e772124339, in PR 8994, to cover a couple of cases missed there.
2018-01-11 12:09:01 +01:00
Jonas Jenwald
b0f524e65c Replace a few occurences of var with let in already ES6 converted web/ files 2017-10-22 16:23:38 +02:00
Jonas Jenwald
33b1d1b20a Fix a PDFHistory regression with document hashes of the nameddest=... form
Unfortunately I've just found out that this isn't working entirely correct; my apologies for accidentally breaking this in PR 8775.

Compare e.g. this link: http://mirrors.ctan.org/info/lshort/english/lshort.pdf#page.157, with this one: http://mirrors.ctan.org/info/lshort/english/lshort.pdf#nameddest=page.157.

Notice how in the *second* case, the history stops working correctly.

*The various edge-case regressions in the new `PDFHistory` code is reminding my why I put off the rewrite for so long :-(*
2017-10-09 21:58:54 +02:00
Jonas Jenwald
e772124339 Fix a regression that (effectively) makes PDFHistory.forward a no-op
*It appears that this accidentally broken in PR 8775.*

Note that `PDFHistory.forward` is only used with certain named actions, and these aren't that commonly used, which ought to explain why this error managed to sneak in.

Steps to reproduce the issue (and verify the fix):
 1. Navigate to e.g. http://mirrors.ctan.org/info/lshort/english/lshort.pdf
 2. Click on a couple of links, or outline items, such that the history is populated with a few entries.
 3. In the console, execute `PDFViewerApplication.pdfHistory.back()` one or more times, thus navigating back to a previous viewer position.
 4. In the console, execute `PDFViewerApplication.pdfHistory.forward() one or more times.

At the last step above, no (forward) navigation happens with the current `master`; now compare with this patch.
2017-10-05 13:56:40 +02:00
Jonas Jenwald
04d4faefc4 Remove the this._currentUid property from PDFHistory, since it's no longer needed
Commit 938dffb06b, in PR 8885, removed the only actual usage of `this._currentUid` and it can thus be removed.
2017-10-05 13:38:25 +02:00
Jonas Jenwald
e135c03123 Store the rotation in the PDFHistory 2017-09-09 11:27:05 +02:00
Jonas Jenwald
938dffb06b Reduce the value of UPDATE_VIEWAREA_TIMEOUT and simplify the 'popstate' event handler to avoid subtle bugs
When testing the new `PDFHistory` implementation in practice, I felt that the current value of `UPDATE_VIEWAREA_TIMEOUT` is too large to be truly useful.
The purpose of the timeout is to attempt to address (the PDF.js part of) https://bugzilla.mozilla.org/show_bug.cgi?id=1153393, and it's currently fairly easy for the user e.g. close the browser before the timeout had a change to finish.

Obviously, the timeout is a best-effort solution, but with the current value of `UPDATE_VIEWAREA_TIMEOUT` it's not as useful as one would want.
Please note that lowering it shouldn't be a problem, since it still prevents the browser history from updating at *every* 'updateviewarea' event or during (quick) scrolling, which is all that's really needed to not impact the UX negatively.

---

Furthermore, with this lower timeout, we can also simplify the part of the 'popstate' event handler that attempted to update the browser history with the current position before moving back. In most cases, the current position will now already exist in the history, and this *greatly* decreases the complexity of this code path.

The main impetus for this change though, is that I unfortunately found that given the asynchronous nature of updating the browser history, there is some *edge* cases where that code could cause history corruption.
In practice, the user could thus get "stuck" at a particular history entry and not be able to move back. I haven't got any reliable STR for this, since it's so difficult to trigger, but it involved navigating around in a document such that a number of destinations are added to the browser history and then changing the rotation before going back/forward in the history.

Rather that attempting to patch this code, and making it even more difficult to understand than it already is or adding more asynchronous behaviour, by far the easiest solution is to remove it and simply rely on the (lowered) `UPDATE_VIEWAREA_TIMEOUT` instead.
2017-09-07 21:02:25 +02:00
Jonas Jenwald
b7c4d788ed Prevent a temporary position from being added to the history while a destination is scrolled into view
Since e.g. zooming can occur when navigating to a new destionation, ensure that a resulting 'updateviewarea' event doesn't trigger adding of a *temporary* position to the browser history at a bad time.
2017-09-07 16:25:01 +02:00
Jonas Jenwald
077195d8ce Ensure that the PDFHistory._updateViewareaTimeout is always reset when the history is updated 2017-09-07 11:37:23 +02:00
Jonas Jenwald
0ac1fba2f9 Prevent PDFHistory._tryPushCurrentPosition() from effectively becoming a no-op if the document hash contains an invalid/non-existent destination
By using the (heuristic) `POSITION_UPDATED_THRESHOLD` constant, we can ensure that the current document position will be added to the browser history when a sufficiently "large" number of `updateviewarea` events have been dispatched.
2017-08-30 19:45:13 +02:00
Jonas Jenwald
0d58bb5512 Temporarily add the current position to the browser history when the viewer is idle
This patch attempts to address an issue in the old `PDFHistory` implementation, where the current position wouldn't be correctly saved when the browser was closed.
In theory this *should* already be working, however as the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1153393 showed, it seems that both `pagehide` and `beforeunload` arrive to late to successfully update the history during closing.

Hence a timeout is used to *temporarily* add the current position to the browser history when the viewer is idle.
Note that we need to take care not to update the browser history too often, since that would render the viewer more or unusable. Furthermore, if the timeout is *too* long it may end up effectively disable this whole functionality.

The `UPDATE_VIEWAREA_TIMEOUT` constant is thus a heuristic value, which we may need to tweak taking the above into account.
2017-08-30 19:45:13 +02:00
Jonas Jenwald
133d06e9a4 Re-write PDFHistory from scratch
This patch completely re-implements `PDFHistory` to get rid of various bugs currently present, and to hopefully make maintenance slightly easier. Most of the interface is similar to the existing one, but it should be somewhat simplified.

The new implementation should be more robust against failure, compared to the old one. Previously, it was too easy to end up in a state which basically caused the browser history to lock-up, preventing the user from navigating back/forward. (In the new implementation, the browser history should not be updated rather than breaking if things go wrong.)

Given that the code has to deal with various edge-cases, it's still not as simple as I would have liked, but it should now be somewhat easier to deal with.
The main source of complication in the code is actually that we allow the user to change the hash of a already loaded document (we'll no longer try to navigate back-and-forth in this case, since the next commit contains a workaround).

In the new code, there's also *a lot* more comments (perhaps too many?) to attempt to explain the logic. This is something that the old implementation was serverly lacking, which is a one of the reasons why it was so difficult to maintain.

One particular thing to note is that the new code uses the `pagehide` event rather than `beforeunload`, since the latter seems to be a bad idea based on https://bugzilla.mozilla.org/show_bug.cgi?id=1336763.
2017-08-30 19:45:13 +02:00
Jonas Jenwald
388851e37b Add a isDestsEqual helper function, to allow comparing explicit destinations, in pdf_history.js 2017-08-30 19:45:13 +02:00
Jonas Jenwald
28ce3b6185 Rip out the current implementation of PDFHistory
The current implementation of `PDFHistory` contains a number of smaller bugs, which are *very* difficult to address without breaking other parts of its code.
Possibly the main issue with the current implementation, is that I wrote it quite some time ago, and at the time my understanding of the various edge-cases the code has to deal with was quite limited.
Currently `PDFHistory` may, despite most of those cases being fixed, in certain edge-cases lock-up the browser history, essentially preventing the user from navigating back/forward.

Hence rather than trying to iterate on `PDFHistory` to make it better, the only viable approach is unfortunately rip it out in its entirety and re-write it from scratch.
2017-08-30 19:45:13 +02:00
Jonas Jenwald
223c429357 Fix inconsistent spacing and trailing commas in objects in web/ files, so we can enable the comma-dangle and object-curly-spacing ESLint rules later on
http://eslint.org/docs/rules/comma-dangle
http://eslint.org/docs/rules/object-curly-spacing

Given that we currently have quite inconsistent object formatting, fixing this in in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead.

*Please note:* This patch was created automatically, using the ESLint `--fix` command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch.

```diff
diff --git a/web/pdf_thumbnail_view.js b/web/pdf_thumbnail_view.js
index 002dbf29..1de4e530 100644
--- a/web/pdf_thumbnail_view.js
+++ b/web/pdf_thumbnail_view.js
@@ -420,8 +420,8 @@ var PDFThumbnailView = (function PDFThumbnailViewClosure() {
     setPageLabel: function PDFThumbnailView_setPageLabel(label) {
       this.pageLabel = (typeof label === 'string' ? label : null);

-      this.l10n.get('thumb_page_title', { page: this.pageId, }, 'Page {{page}}').
-          then((msg) => {
+      this.l10n.get('thumb_page_title', { page: this.pageId, },
+                    'Page {{page}}').then((msg) => {
         this.anchor.title = msg;
       });

diff --git a/web/secondary_toolbar.js b/web/secondary_toolbar.js
index 160e0410..6495fc5e 100644
--- a/web/secondary_toolbar.js
+++ b/web/secondary_toolbar.js
@@ -65,7 +65,8 @@ class SecondaryToolbar {
       { element: options.printButton, eventName: 'print', close: true, },
       { element: options.downloadButton, eventName: 'download', close: true, },
       { element: options.viewBookmarkButton, eventName: null, close: true, },
-      { element: options.firstPageButton, eventName: 'firstpage', close: true, },
+      { element: options.firstPageButton, eventName: 'firstpage',
+        close: true, },
       { element: options.lastPageButton, eventName: 'lastpage', close: true, },
       { element: options.pageRotateCwButton, eventName: 'rotatecw',
         close: false, },
@@ -76,7 +77,7 @@ class SecondaryToolbar {
       { element: options.cursorHandToolButton, eventName: 'switchcursortool',
         eventDetails: { tool: CursorTool.HAND, }, close: true, },
       { element: options.documentPropertiesButton,
-        eventName: 'documentproperties', close: true, }
+        eventName: 'documentproperties', close: true, },
     ];
     this.items = {
       firstPage: options.firstPageButton,
```
2017-06-01 12:47:47 +02:00
Jonas Jenwald
79e0745a12 Import getGlobalEventBus correctly from web/dom_events.js in various /web files, to un-break e.g. the viewer components (PR 8203 follow-up)
In PR 8203, I somehow managed to mess up the import of `getGlobalEventBus` in *all* files where it's present; my sincere apologies for this!
2017-04-17 00:54:29 +02:00