Better keep track of vertical position in history (in JQuery mode)

[kelson42]

"Back" and "Forward" buttons should bring the user on the proper article (what it does), but as well at the right vertical position in the article (what it doesn't do).

[Jaifroid]

I guess we could record the vertical scroll percentage of the iframe and jump to it on back button/arrow. Currently, our back button also records typing strokes in a search, and I wonder if that should be removed. I for one find it a bit disconcerting to be thrown back into a search when I use back button rather than to be taken back to a previous article.

[kelson42]

To me this sounds not natural that this has to be handled by Kiwix. This shoudl just work (like #678 BTW) because the browser knows how to handle that. I feel this is the symptom of an architectural weakkness. The browser remembers the vertical position in a normal page, so why it does not here? Are we sure this is because of the iframe?

[Jaifroid]

@kelson42 Actually this does work in Service Worker mode. I've just checked.

The issue is that we have two modes of operation, one of them legacy for browsers that don't support Service Worker, and the other one much closer to a "Web View" embedded in an app, where the iframe acts as the Web View. The latter can use all of the native functions of the browser (nearly), while in the former case we have to emulate many of the browser's functions. So, in the DOM-traversal mode (aka jQuery mode) we have to store the history manually, and then we have to shift the history off the stack manually when the user presses the back button. In SW mode, the browser handles all of this.

So the answer to your question about architectural weakness is that this is an artefact of old browser support, but I think the architecture of the app as a whole is very strong (thankis to @mossroy's clear-sightedness precisely on such issues)! 😉

[kelson42]

@Jaifroid Thank you for clarifying that this is a problem only affecting JQuery mode. This was not something I was aware off, as I'm a FF user. I have tested with Chromium and indeed it works fine. To me, the importance of this ticket is consequently halfed. If we can workaround with saving "manually" the vertical position, then this is good to me :)

Concerning the search, it sounds to work properly to me... it is anyway and edge case to click on an article link while the suggestions are open. Not sure removing it is a good idea.

[mossroy]

Thanks @Jaifroid for your support and for taking the time to answer in detail all issues, even when they contain hasty criticism.

The lack of ServiceWorker support in Firefox extensions is becoming a big issue, because it forces us to keep maintaining this ugly "jQuery" mode. This original mode has a lot of flaws, but we don't know a better way when Service Workers are not supported.
If Firefox supported ServiceWorkers in extensions, we could consider this jQuery mode as legacy, stop trying to patch/improve it all the time, and keep it only for deprecated platforms. Unfortunately https://bugzilla.mozilla.org/show_bug.cgi?id=1344561 does not seem close to be implemented.

Is it worth implementing this improvement in jQuery mode? Maybe, if it's not complicated to code, test and maintain.
But we have to keep in mind that images are loaded asynchronously. So the vertical position can change until they are all loaded.

Regarding the architecture of the app, it's certainly not perfect : constructive suggestions, help and PRs are always welcome to improve kiwix-js.

[vishalvikal]

Hi, @kelson42 I am new here and want to work for the open source. Is there anything? I can tackle with. Thanks

[vishalvikal]

I know D3 library. Please hear if there any work related to D3 or javaScript.

[Jaifroid]

@vishalvikal This project doesn't use D3. Issues marked as "good first issue" are those we think may be possible for new contributors, if you have some reasonable JavaScript experience.

[Rajat379]

I am keen on working on this as a first timer, should I work on it straight away?

[Jaifroid]

@Rajat379 You can work on this if you are confident with how window.history is manipulated in JavaScript. Please note there is an upcoming PR #680 which affects history manipulation, and it may be a good idea to examine the code there, as a number of things may well change that would affect any PR you work on. One option would be to wait until that PR has been merged or closed.

[aadi2305]

The verticle position can be stored in session data and on pressing back or forward button, using scrollTop() we can set verticle position of the article. Should I implement it?

[kelson42]

@Jaifroid I have open this ticket 2 years ago, but considering that this would be a very little improvement and that it has been decided to not develop further the JQuery mode; it seems to me this ticket should be closed as WONTFIX. What do you think?

[Jaifroid]

you're right, it works natively in Service Worker mode, and we said we wouldn't add more code to jQuery mode. Only exception might be if it turns out to be a really easy fix, but in that case the issue could be re-opened by anyone wanting to fix it.