I was able to replicate this, the menu disappearing is weird

To the best of my knowledge:

• This only appears to affect singlehtml builds because for multi-page html builds, a menu item navigation click causes the browser to re-display the page contents from scratch, meaning that the sidebar menu reappears in the default closed position.
• There is an existing event handler in theme.js that, based on a comment in there (// Close menu when you click a link.), seems intended to handle these navigation events.
• The mentioned event-handler doesn't appear to get attached to any sidebar menu hyperlinks when I open the singlehtml build output in Firefox. Whether that's due to a regression somewhere, I don't know, but the cause is an empty resultset from the .wy-menu-vertical .current ul li a CSS selector query.

This affects some documentation in Debian, and I've provided a patch downstream in the relevant bugthread at https://bugs.debian.org/1075914 for that (although I'm not 100% certain whether it's the best way to fix this!).

also, cc'ing @kebekus @nienn (because this seems similar to #1177 which I was reading before discovering this more-relevant bugreport)

• This only appears to affect singlehtml builds because for multi-page html builds, a menu item navigation click causes the browser to re-display the page contents from scratch, meaning that the sidebar menu reappears in the default closed position.

There is an exception to this: hyperlinks to the same .html page that is already being viewed in the web browser. This is intended, I think, to be exactly the set of items with the current CSS class applied to them.

Given that, I think my downstream patch is incorrect (and I've added a message to note that there). Instead of removing the .current part of the query unconditionally, a couple of options that occur to me are either to add the current CSS to the root of the table-of-contents tree in the sidebar (this would be a Sphinx upstream change, and could affect other themes), or -- and I don't really like this, but am suggesting it since it may be feasible -- detect that the project is singlehtml in the JS code, and conditionally omit the .current part of the query in that case.

Although I think it's worth being careful about side-effects, and would benefit from discussion, initially I lean towards the idea of adjusting this behaviour in Sphinx. In single-document Sphinx builds there isn't really a logical notion of current location within the graph of documents, so it might be valid to consider the root of the table-of-contents tree as the current location.

If anyone from this thread has time to test the potential fix in #1588, I'd be grateful!

Strictly speaking, it only resolves the second part of the reported navigation problems; selectively-quoting the relevant part of the bugreport:

Clicking on a top-level entry goes to that location but does not close the menu.