Comment 4 for bug 20871

The toolbar button does not address this bug. It does not manage pages as a stack. I think it is based upon some web-browser user interface work that displayed the title of recently visited pages in a drop down list, based upon when the page was viewed. This is a reasonable way to present a browser history.

However, under evince, the drop down menu often displays page numbers, since pages in pdf files do not have titles. Worse, the list is presented in a mysterious order. Surely, any user interface that requires the user to remember which page or chapter contained a previously clicked link is broken.

Regardless of whether the current evince behavior is "better" than standard web browser interfaces (see upstream bug), gnome should standardize on a single browsing paradigm, and Nautilus provides a reasonable user interface. However, nautilus provides a breadcrumb bar, and it's not clear that a breadcrumb bar would be useful with evince; in practice, it would contain a bunch of page numbers or section headings.

The current situation introduces a non-standard set of navigation primitives, and still (after 4 years) does not support alt-left. Also, using the mouse to navigate backwards in this UI is awkward. In the best case, following a link backwards requires two mouse clicks. However, after you have clicked a few links, you have to search for the link (page number) you want in an apparently randomized list.

There was some debate over the correct semantics for a back button upstream a few years ago. Xpdf only pushes things onto the stack when links are clicked; it does exactly what a web browser does. This seems like the right approach. Also, the debate over web browser back button user interfaces has evolved a bit since this bug was filed. Perhaps the current 'back' toolbar button could be replaced with one that clones firefox's interface.