Incorrect UX for back navigation after search in docs

[mqudsi]

The UX for navigating after a search in the documentation in incorrect. Upon searching in the documentation, the search takes over the contents of the current page, i.e. it is not displayed in a lightbox or pop-up div. In this case, the use of the back navigation button should act as exiting the search and returning to the page in the documentation that the user was on prior to triggering the search feature.

In practice, using the back button goes back to the 2nd to last page the user was on before triggering search, and a backwards-then-forwards double navigation is required to end up on the page that the user was on before search.

The solution is to use the history push state api to add an entry to the backwards navigation stack that would return the user to the last-viewed page upon triggering the search after clicking the backwards navigation button.

(Yes, I am aware that it is possible to close the search box and go back to the last page via other means. The point is that the content of the window act as if a full navigation has taken place, in which case the most natural means of returning to the original content for the user is to press the back button and not escape, etc.)

[ecstatic-morse]

This feature is already implemented and works as described on Firefox 64. Perhaps the author's browser doesn't support the history API or feature detection is not working correctly.

Edit:

It looks like the history api doesn't interact well with file:// URIs. Maybe this is what @mqudsi was experiencing.

[GuillaumeGomez]

It's not working the same way on file:// urls but it should indeed.

[GuillaumeGomez]

Here's the PR for reference: #28400

[mqudsi]

Yes, I was working with locally compiled documentation.

[mqudsi]

Fwiw; I believe the correct solution here is to trigger an actual Page navigation upon search, such that use of the history api not needed.

[GuillaumeGomez]

@mqudsi: You don't want that. In case you're looking for an element on the current page, it'll reload the whole page, which isn't very nice. I tested to ren-enable the history management locally with file:// and it seemed to work so I'll send a PR for it.

[mqudsi]

@GuillaumeGomez I mean only when search has already taken over the page (so the contents are completely hidden and navigation or ajax manipulation looks the same). Remember this is local, so there is no network-associated delay.

[GuillaumeGomez]

Try the iterator trait page locally. 😈