This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Entries potentially get added to the JumpList (through checkAddEntry via BaseAction's updateComponent method) whenever a keyTyped event occurs (DefaultKeyTypedAction). This includes keyTyped events that related to a CTRL key sequence (for example, CTRL-G to bring up the Goto line dialog). This behavior seems inconsistent because if the same action is triggered via the menu item or toolbar button, the caret position is not added to the JumpList (reproducible in the NetBeans IDE). It would be better if key typed actions that don't relate to actually inserting text are not added to the JumpList. The current implementation causes a serious bug in our product if I associate keybindings with the JumpListNextAction and the JumpListPrevAction. The problem is that if the user presses the keybinding and the action causes a different frame to come forward (in our application, the Editors can be in separate frames), the JumpList becomes corrupted because the keyTyped event related to pressing the accelerator for the JumpList action causes the caret position of the text component that is losing focus to get added to the JumpList (but after the JumpList has already changed the currentEntry to refer to the text component that is about to gain focus). For some reason, if the 2 text components are in the same frame this keyTyped event is never received by either text component-- it only is in the case where the text components are in separate frames that the keyTyped event is processed. I tried various hacks in the code to get around this, but nothing was entirely successful. Hopefully the original authors of this code will have some better ideas!
Apologies but I'm a bit confused. The BaseAction.updateComponent() that checks the BaseAction's flags and possibly calls JumpList.checkAddEntry() gets called from actionPerformed(ActionEvent) so it is trigerred in each action's execution. Only the actions that modify the document should have the BaseAction.SAVE_POSITION flag that allows for JumpList.checkAddEntry() call. The Ctrl-G (ExtKit.gotoAction) is not among them as well as BaseKit.jumpListNext/PrevAction. Are you sure that the JumpList is causing the problematic behavior if the two panes are in the same frame? Isn't that rather any problem related to focus transfer?
It is true that ExtKit.gotoAction does not have the BaseAction.SAVE_POSITION flag (which is why it does not get added to the JumpList if you trigger Goto from a menu item). However, DefaultKeyTypedAction does have the SAVE_POSITION flag. So if you trigger an action via its keybindings (for example, CTRL-G), the position gets added to the JumpList through the DefaultKeyTypedAction. It is inconsistent that the caret position before the goto dialog opens gets saved based on whether or not you trigger the action via a keybinding. This is true for a number of user actions and causes the specific problems in our application that I mentioned. Please let me know if this still is not clear enough.
I see. So we will unset the SAVE_POSITION from the DefaultKeyTypedAction and call the JumpList updating manually only in case when the keystroke does not get filtered out and presents an insertable content. This should be doable into 5.0.
Reproducible in the main trunk. Open a document and use Navigate -> Go To Line several times, then try using Back (Alt+K, editor's toolbar or Navigate main menu again). There are no saved positions, the 'Back' action does not do anything. Then close the document and do the same thing this time using CTRL-G to invoke the 'Go To' dialog. The jump list contains positions and the 'Back' action navigates back through the lines you went to.
moving opened issues from TM <= 6.1 to TM=Dev
Let's try to do this in 7.0.
it's not clear from initial description how to verify the issue. but latest steps with ctrl-g and navigate|go to line both work same way, without jump list filling (atl-g do not enbable toobar back, navigate|back also change nothing). not reproducible with 090409 feel free to reopen if there are others reproducible cases