Currently the back/forward navigation works only in textual editors. The problem is that if the user switches manually to a different "non-textual" tab (e.g. diff
viewer, profiler results) the user cannot use the navigation to get back to the textual editor. Note that the toolbar buttons are located only in editor toolbars of
textual editors. Similarly if the focus is in the GUI builder and the user switches into the design view by clicking the "Design" button, she/he cannot get back to
the textual editor. Also if the user switches between textual editors by clicking their tabs or uses the "Ctrl-Tab" features, the back/forward buttons don't work.
The back/forward buttons should be located in main toolbar and they should work also for non-textual editors.
Note that even though I'm filing this issue as part of the 6.1 planning, the real intention is to address this issue in one of the upcoming releases.
i briefly went through editor code and my understanding is that navigate/back and navigate/forward actions do not need
focused editor window to work. so they can be enabled even when a non-editor window is focused and they can be also
added to the global edit toolbar.
Just note it also needs to work for the use case when the user switches between 3 different GUI builders by clicking their tabs. For example the user clicks java
file tabs in the following order (all tabs have the gui builder selected):
GUI A -> GUI B -> GUI C
Then clicking the Back button should switch the selected tab from GUI C to GUI B.
i think the only reason why back/forward actions are disabled in the main menu is that they inherit from some common
editor action class which is disabled when no editor window is focused. this should be easy to fix.
reassigning to editor team for evaluation
It's not going to be that easy. The navigation history is only bound to navigating through the code (eg. ctrl+mouse
click). Please note that even with ordinary java files the buttons are not enabled when simply switching between tabs.
The actions were never meant to work like that. They are mimicking navigation buttons in a web browser, which also
record only navigation through hyperlinks, but ignore switching tabs.
The desired behavior is that the global actions record "hyperlinks" (go to source/declaration), and also switching tabs, opening new tabs, and maybe also
switching multiviews (e.g. source <-> form).
Note that the current behavior doesn't really work like in browsers as back/forward actions in browsers don't work cross tabs at all. In our case they do. But I
understand your point they don't currently track what we need them to track to make them global.
Similar comments from issue #134218:
2. The back and forward buttons found at the top of each editor window work in strange ways that make little sense. I
suggest they should work like a browsers back/forward buttons by going back/forward to the document previously
displayed, in order that they were displayed. So if I have documents open and click on them from left to right and
then use the back button 5 times they should display from right to left. Clicking on forward 5 times would display
them again from left to right. I understand they currently follow the ctrl click links I made so perhaps the default
could be to do that and by ctrl clicking they would go back forward as I have discribed.
4. When I split my IDE into multipule editor windows, moving a editor window from some section to another should
display the previously accessed editor window in the old section. As though I had clicked the back button as per my
description of how the back button might work. At the moment it selects the documen at the end tab. It makes no sense
and this is very frustrating.
Hello, I am not sure whether it is related to this topic but some time ago I have implemented back/forward navigation as
part of the contrib/bookmarks module (I guess it is now under main/contrib/bookmarks). The implementation depends on
some non standard modules (and would have to be re-written) but the API is general and simple and worked for us when I
was in Nokia/NSN ... Maybe the person looking at this issue might have a look there for some inspiration. The main
features of the forward/back navigation in our case was that it was pluggable by any module. The other feature was it
was transient (non-persistent) unlike bookmarks which are persistent.
For the API part see: