Reopen the last article after switching between menu items

[mossroy]

A cookie might keep the last article

[Jaifroid]

Kiwix-js-windows now implements re-displaying the last article after switching back from "Config", without re-loading the article. (It also disables the link back to the article if the user has switched CSS display mode, as this necessitates reloading the article). I'm in the process of backporting to kiwix-js to commit just the switching between tabs to a new branch built on the main branch (so as to be able to make a PR for testing from main).

The testing branch is here: https://github.com/kiwix/kiwix-js/tree/Return-to-last-article-from-config-without-reloading , but it has no changes yet.

If anyone wants to test the full feature set, they need to do so on kiwix-js-windows until I edit this message.

Edit: backport is now complete - see PR #291 .

[mossroy]

As discussed in #291, I think switching between menus should "naturally" keep the context. Without doing anything special, the user should see its last article after going to and back from another section. It should only be a matter of not emptying a div, in order to be able to see its content when un-hiding it. That would be the first step.

A second step would be to store what's necessary in a cookie, so that to be able to re-open the same article after closing/re-opening the app. Which is a bit more complicated because of the different ways to open a ZIM file

[mossroy]

I renamed this issue, to narrow it to what can be implemented for now : be able to return to the same article after going to another section (settings, or about) As it's not possible to reopen the ZIM file automatically (in a portable and cross-browser way), it's not possible to do more.

[Jaifroid]

OK. It is possible to remember the last page for each ZIM and load it after the user has picked the ZIM. We simply store a cookie value like lastPageLoaded=Page_d'accueil@wikipedia_fr_all_novid_2018-10.zim and load it if the picked ZIM name matches. In Web context, it's not so useful, but in app context it can be very useful (albeit that it has privacy implications).

[mossroy]

You're right

In Web context, it's not so useful, but in app context it can be very useful

That's why I think it's better to keep it in kiwix-js-windows, without backporting it for kiwix-js (where it would only be useful for the dead Firefox OS...).

With this renamed issue, it should be not necessary to store the info in a cookie, and there will be no privacy concern

[Rbcoder1]

I am working on #523 but I need to build this functionality of returning to last article

That's why am solving this issue first

[Rbcoder1]

We just need to implement the functionality of returning to last article after unclick on config & about button

I thing it will done using hiding and unhiding of that section/div. Using some dom-manupulation

[Rbcoder1]

I working on it

[Jaifroid]

@Rbcoder1 Exactly!

[Rbcoder1]

Ok I Make PR for it Thank for better suggestion

[Jaifroid]

@D3V-D Issue is partially fixed in that the code to go back to the article view and unhide any article that is currently loaded is in the codebase, but what hasn't been successfully implemented to date is the "unclicking" action on the menu buttons, so you could click on Config, then unclick it and the loaded article would show.

[D3V-D]

@Jaifroid Yeah I realized this a bit belatedly. In the meanwhile, I might be interested in working on this issue, but I'll take a closer look at it first.

[D3V-D]

Okay, so for unclicking, is that whenever I click on the config section the second time? Or is it when I'm on the config section and I click anywhere on the section that isn't a button and it un-highlights the config tab?

I'm a bit unsure as to when or why we would want to go back to the article by "unclicking"

[Jaifroid]

@D3V-D Effectively the "Config" button should remain selected while Config is showing, and then when you click again on it, the button is visually deselected and we return to whatever article is loaded. When a user clicks on "Home", conversely, the landing page will be loaded again. Same with the "About" button (should act same as Config).

You can see, roughly, how this should work by looking at https://pwa.kiwix.org, where that version (with a somewhat different UI) works in this way. To see it properly in action, you need to load a ZIM.

[D3V-D]

@Jaifroid Okay, thanks for the PWA link, I see what you mean now! Clicking on the tab the second time should take you back to the article, and clicking the home tab should reload it. I remember a while back I did the drag-over feature, where when dragging it would open config, but once you drag-exit it went back to the ZIM, I think without fully reloading it (I can check again), maybe that would work just fine here as well? And reloading the ZIM should be easy enough when clicking home

[D3V-D]

Actually I think the PWA may reload the ZIM when unclicking, but I think the Kiwix-JS extension doesn't when drag-exiting.

EDIT: Nevermind, after some testing I don't think either reload the ZIM entirely.

[Jaifroid]

The infrastructure is all there, it's just about hooking the relevant functions into the Config and About buttons, so they unhide the main article when clicked if they are currently selected. And then there's the cosmetic issue of ensuring the buttons look like they are clicked and unclicked.

I don't think the PWA actually reloads the ZIM when clicking on Home, it just calls the goToMainArticle() function just as the current Home button does in Kiwix JS. I don't actually think you need to touch the Home functionality except perhaps to ensure that the Config and About buttons are visually deselected when clicking it. This may already be the case, actually, so I think it's just about hooking up the buttons to the relevant function (I'll check what that function is called in a moment).

[Jaifroid]

@D3V-D It's uiUtil.returnToCurrentPage(). It looks like it deselects the currently pressed buttons already.

[D3V-D]

@Jaifroid Okay, thanks for the info! Hopefully it's as easy as it sounds, but I'll probably work on it sometime next week