Navigation history should be empty at ZIM opening time about apple

[BPerlakiH]

@kelson42 it seems to be a redirect issue from:
kiwix://1F0E1CD1-14A2-3125-F1CD-55C318022344/home
to:
kiwix://1F0E1CD1-14A2-3125-F1CD-55C318022344/home#list--0

I am not sure about this to be honest. Should this be fixed on the reader side?
I can only think of hacks and workarounds for this.

[kelson42]

@BPerlakiH There is no elegant way to remove ZIM redirects from the navigation history?

[BPerlakiH]

@kelson42 There's a read only list of "backItems" added to the history, and from what I can see not really editable.

We can override at the back button level (is it enabled or not), but the user can still swipe back (at the edge of the screen) to the former page, like so:
https://github.com/kiwix/kiwix-apple/assets/6784320/4296dc28-5ae9-4cf5-bded-c72825a5f198

Possibly our best option is to block the navigation in the first place, I will have a look how we could distinguish which is a redirect and which is a user initiated navigation.

[kelson42]

postponing to 3.5.0

[BPerlakiH]

I did further investigation into this, and so far haven't found a good enough solution.
Intercepting the navigation action as of: https://developer.apple.com/documentation/webkit/wknavigationdelegate/1455641-webview.
Returning .cancel, still adds the url to the navigation history.
At the same time the navigation history is read only.

In one attempt I managed to identify similar redirects, within the navigation handler, by comparing the current URL with the former one, and if it was the same (by subtracting the #something at the end), than I was able to disable the back button.
In case of the Water Treatment ZIM, this would work by:

"BrowserViewModel.navigationAction .allow for: kiwix://1F0E1CD1-14A2-3125-F1CD-55C318022344/home"
"BrowserViewModel.navigationAction skipped old: kiwix://1F0E1CD1-14A2-3125-F1CD-55C318022344/home due to redirection to: kiwix://1F0E1CD1-14A2-3125-F1CD-55C318022344/home#list--0"
"BrowserViewModel.navigationAction .allow for: kiwix://1F0E1CD1-14A2-3125-F1CD-55C318022344/home#list--0"
"BackListURLs:: skipping: kiwix://1F0E1CD1-14A2-3125-F1CD-55C318022344/home"

The side effect of this is that it is still possible to navigate back to the old url, by swiping back, as we only disable the button itself.
Another side effect of this, that eg. in Wikipedia articles, where we have footnotes with numbers, the same url structure is used:

"BackListURLs:: skipping: kiwix://1F0E1CD1-14A2-3125-F1CD-55C318022344/home"
"BrowserViewModel.navigationAction skipped old: kiwix://FE516A05-6C7A-38CE-8EF6-1FDEECBB8F3D/A/Online_encyclopedia due to redirection to: kiwix://FE516A05-6C7A-38CE-8EF6-1FDEECBB8F3D/A/Online_encyclopedia#cite_note-3"

So going from here:

to here:

with this solution, would still disable the back button, which is not something we want (see the back button is disabled, when it should not be).

At the moment, I don't think it is something we can fix in a reliable manner, I am suggesting to either close it as non-fixable or postpone it. Maybe it will be easier to fix this while scrapping the content.

[kelson42]

@BPerlakiH You say that decidePolicyForNavigationAction does not apply to gesture navigation?!

I believe that:

• You need to identify redirects in the back history
• By moving back/forward, you need to handle this yourself and skip redirects to go straight to the end target (so the source page if this is goBack)
• If there is only redirects in the back navigation history, disable the back button

[BPerlakiH]

You say that decidePolicyForNavigationAction does not apply to gesture navigation?!

It's even worse, it is not applying at all. Meaning even if I return .cancel, the navigation still ends up in the navigation history.
Based on what is in the history, the user can navigate back and forth. We can only override the back-button logic, between what's in the navigation history, and how the back button is presented on the UI (enabled or not). Even if we disable the button, based on the "real" navigation history, the system allows to navigate back by swiping.

The other issue is how to reliably distinguish between a real redirect, like in the Water ZIM, and a user initiated one, like in the Wiki footnote. I will have a second look at this, maybe as you suggested there's more to it in the navigation history itself, than at the point of navigation handler.

[kelson42]

The other issue is how to reliably distinguish between a real redirect, like in the Water ZIM, and a user initiated one, like in the Wiki footnote. I will have a second look at this, maybe as you suggested there's more to it in the navigation history itself, than at the point of navigation handler.

I have no clue what you are talking about here (or in your comment before). There is only one kind of redirects IMHO, the documented as such in the ZIM spec.