fava
fava copied to clipboard
Firefox: view jumps after editing a directive (scroll-linked positioning)
Constraints
Happens in Firefox 98.0 on Ubuntu, but not on Chrome (same OS).
Happens in the scrolling Account view (eg url.com/ledger/account/Assets:Current/
) but not in the Journal view.
Bug
After editing a directive (Transaction, Note etc) by clicking the date, editing and then hitting save, the scroll view will jump seemingly randomly, normally putting the edited entry somewhere near the top, but sometimes out of the top.
Extra info
I get the following message in the console:
This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://firefox-source-docs.mozilla.org/performance/scroll-linked_effects.html for further details and to join the discussion on related tools and features!
I'm not familiar enough with Svelte to dig into why this might be happening.
Possibly related Svelte issues:
- https://github.com/sveltejs/kit/issues/2794
- https://github.com/sveltejs/kit/issues/2733
Hey, thanks for the report. An even simpler way to reproduce this is to just press the r
key to reload the account journal (which is also done on saving of an edited entry). This reloads the contents on the page (everything in the <article>
element) and replaces it.
I assume that stuff like the charts (which are rendered on the frontend) cause Firefox to think that enough content changed that it needs to scroll to the top (or Firefox is quicker to jump before waiting for these things to render).
[The console message that you mention is caused by the CodeMirror editor and unrelated to this issue. The issues that you linked to are about SvelteKit, which Fava doesn't use (it only uses Svelte itself, the routing is done by our own code). So those issues shouldn't really be too related to this.]
A possible workaround for Firefox in our router might be trying to restore the scroll position after changing the contents of the <article>
element.
Thanks for looking into it! Interestingly it doesn't happen on Firefox 91.8.0ecr
.
(For my own purposes I'm happy to just minimise the charts when I'm doing editing.)
I don't think there's much we can do here (in the future moving more of the rendering to the frontend might fix this).