Support adding pages, in addition to regular destinations, to the browser history and use it with thumbnails (issue 12440) #12493
Conversation
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.
…wser 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.
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.
|
/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/6f80a2d3dfa6d8e/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/6f80a2d3dfa6d8e/output.txt Total script time: 3.91 mins Published |
|
Wouldn't we then want to do this in more situations? Clicking a thumbnail changes the page number, so then I'd expect this to also work when entering a page number in the textbox or via the hash parameters, and also when clicking an outline item. I'd say those are all signs of navigation within the document. What do you think? |
That's somewhat more difficult to implement well, given that we support page labels in addition to just page numbers; hence that's not something I want to worry about here (or even at all).
But, that's been supported from the start[1]...
... and so has this, since those are just destinations, given that it's the primary reason for [1] To the extent that doing so is feasible, since the old |
You're completely right; now that I tried again it clearly works. Not sure how I tried it yesterday, but sorry for the noise. The patch seems to work just fine, so let's do this. Thanks! |
It's very possible that your initial testing actually uncovered a bug, since all of this is unfortunately pretty complicated[1]. If so, please let me know if you manage to come up with a way to reproduce it. No worries; thanks for taking the time to test this and think about the various cases involved. [1] Unless you simply found an edge-case, which is purposely not implemented because doing so would complicate and/or break the primary functionality of |
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.
Fixes #12440