slidewiki-platform icon indicating copy to clipboard operation
slidewiki-platform copied to clipboard

SWIK-2088 Fix reloading presentation mode starting on the wrong slide

Open rmeissn opened this issue 6 years ago • 3 comments

Prior to this PR, when reloading the page in presentation mode, the slideshow always jumped to the first slide instead of the last shown one. It will now correctly reopen the last shown slide.

EDIT: The following description is now implemented with localstorage instead of cookies. All other information are still valid. Basically I'm setting a cookie (valid for 15 secs) if the page is reloaded and read this cookie again as soon as the page has finished reloading. If there is a slide hash in the cookie, I'll set this hash again and in result the correct slide is opened up. After reading the cookie, the cookie deleted.

This should theoretically work fine with PR #1008 .

This might still block SWIK-1775 - not sure yet.

rmeissn avatar Sep 28 '18 09:09 rmeissn

This might be much easier and less code if localstorage is used instead of a cookie.

rmeissn avatar Sep 28 '18 13:09 rmeissn

@kprist This branch is not using a cookie anymore. Just localstorage to store the last shown slide. It's less code and more convenient than a cookie.

Explanation of behaviour: If you request presentation mode with a fragment (hash) (!) in the URL, this fragment is not transferred to the server, rendering and preloading the page. This is the default browser behaviour. Thus reveal.js is initialized without a fragment and will always start at the first slide of a deck. This branch is saving the fragment in localstorage in order to restore it after a page reload (sole purpose of this branch!). It's not possible to start on a specific slide by manipulating the fragment of the URL (see following paragraph). If a specific slide is opened fro view mode in presentation mode, the URL is different than when the slide is exchanged by reveal.js in presentation mode. In the first case we add a URL path segment (that is transferred to the server) and in the latter one reveal adds/exchanges the fragment of the URL (that is not transferred to the server). As the fragment should eventually be available as soon as client side mounting is executed I've tested a lot of different methods to get it from the URL. Unfortunately I found no way to get it. Server side rendering seems to rewrite this somehow by initializing reveal.js without a fragment.

It's not possible to do a page reload and to manually manipulate the URL fragment, as this is again triggering the server side rendering process.

I don't think your second paragraph is limited to this branch, or is it?

The current localstorage entry time to live is set to 15 seconds (to also support slow internet connections or large decks). If you reopen presentation mode for the same deck within these 15 seconds, it will show the last shown slide again, even though you e.g. wanted to open presentation mode from deck view (so to open the first slide).

I'm happy about any suggestions to improve the behaviour (without rewriting how we set up reveal.js).

rmeissn avatar Oct 24 '18 08:10 rmeissn

Thanks for the clarification and the info about the time limit. Assigning to @kadevgraaf, as I don't think it should be merged now, seems like a bug with reveal.js.

kprist avatar Oct 24 '18 08:10 kprist