lentinj
commented
3 months ago The links are simply /life/@species, without any local state. We make no attempt to add this state---as you say, it'd get stale. What (should) happen is we intercept the link and use set_treestate to do the changes to the tree instead:
This generally seems to work, and we have no reason to propagate existing query arguments, since set_treestate only changes the tree state we asked it to. So your settings are preserved.
However, it's not perfect:
- Middle-clicking a search result doesn't preserve settings in the new tab, because the above event handler doesn't get involved
- We only preventDefault once closeAndLeap worked, so any exception on the click event will result in navigating to a new page (without preserving your settings, again because they're not in the URL)
My guess is you're experiencing the latter, a javascript error is being masked by the navigation to a fresh page, which has none of your settings.
wolfmanstout
If I click on one of the convenient "popular places" links listed when hovering over the search bar, it resets any settings I've changed, such as the visualization shape. This is because it is not passing along the query args.
Simply passing along the query args when generating these links wouldn't truly fix the issue, because this list is populated when the page is first loaded and settings are generally changed after that point. These links either need to invoke javascript that dynamically defines where to navigate to, or else they need to be repopulated any time the query args are changed.
This bug is also present in a lesser form for the links that show up after a search query is entered: if the settings are changed after this point and then one of the links is clicked, it'll reset the settings (for the reason explained above, that the query arg changes are not propagated).