As seen, the vertical scroll position is preserved when reloading.
But scrolling the gantt chart horizontally causes the scroll position to be lost.
Now reload the page and instead scroll vertically and click the Reload button.
Observer how the vertical scroll position is now restored just fine. Do it again - no problem.
But scroll vertically, and the scroll position is lost.
In both cases, the page must be reloaded to get any scroll preservation to work again.
Tested with Gantt 6.2.0 and 6.2.2. Sample attached for debugging.
StateProvider.setup('memory') is only used when the state is saved to and received from a server, which is not the case. If you change 'memory' to 'local', when the state is saved to the local storage, your demo works as expected. Also, keep in mind the comment from the https://bryntum.com/products/gantt/examples/state/ demo:
#1 - State must be ready at app launch time
Stateful widgets consume state data during their construction, which cannot be
done asynchronously. This can be handled with an AJAX fetch issued before
widgets are created (as in this example), or by "rendering" the state data on
the server and returning it as content in the page.
Since I can't provide a sample with a backend, I'm merely simulating that gantt is reloaded "later" using the same state. And as you can see, state is restored - sometimes. As long as I don't do both vertical and horizontal scrolling.
Changing the stateProvider to use local storage does not solve the problem. Scrolling horizontally destroys the vertical scroll position, and Gantt ends up in a broken state where it never restores the vertical scroll position once you have scrolled it horizontally. You will have to wipe the state from localStorage (or memory by reloading the page if you use 'memory' for StateProvider). When using localStorage to store the state, you can of course reload the entire page, rather than using my custom Reload button, and you can still reproduce the bug.
New video attached as proof. Also, please see the video and code samples attached initially.
This looks like a bug, might be something related to when the config is used as a hook. I have opened this ticket to investigate this issue: https://github.com/bryntum/support/issues/11379. Because without passing the reload method, everything works.
