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.

Bug 17320

Summary: Output window/view has inconsistent behavior when a new error is made "current"
Product: cnd Reporter: David-john Burrowes <davidjon>
Component: TerminalemulatorAssignee: ivan <ivan>
Status: NEW ---    
Severity: blocker CC: cledantec
Priority: P4 Keywords: UI
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on:    
Bug Blocks: 29448    

Description David-john Burrowes 2001-11-06 01:27:42 UTC
In the output view, if I use the up or down arrow key to move to the next error, that error is immediately shown in the source editor.
If, however, I use the mouse to click on something other than the hyperlink, the error gets highlighted as if it is the current error, but the source editor 
window doesn't get updated to show the offending line.  It seems to me that the two should have the same effect.  (I'm not sure which is "better" 
however).
Comment 1 akemr 2001-11-19 10:58:37 UTC
Reassign to me.
Comment 2 akemr 2001-11-19 13:22:25 UTC
This is as designed behaviour.

CCing Chris, because I implemented this (not update editor
after clinking on no-hyperlinked part of error) on his request.
Comment 3 Chris Ledantec 2001-11-19 14:15:19 UTC
agreed. this is as designed. if we start letting the user click on
'unclickable' parts of the error then it makes no sense to mark some
parts as a link... 

with the keyboard navigation it might be better to have 'space'
indicate that the current error should be focused in the editor window
but i think this would only make sense if it was clear that the link
had focus and i'm not sure that is available.

cL
Comment 4 David-john Burrowes 2001-11-19 18:54:16 UTC
So, I'm changing this to an enhancement request, because I do think this behavior isn't good.  

One of the reasons it isn't good is that if the "current" error is the first, and the user wants to 
look at error 73, for example, and she uses the keyboard to do this, she must pass over every error 
in between (which will potentially open a bunch of files unnecessarily).

Also, by analogy with web browsers (which is an applicable analogy since this is using hyperlinks), 
moving the focus to a hyperlink shouldn't automatically activate/follow the link.

Because this is a custom component, it should be quite possible to provide hyperlinks with a 
distinct keyboard focus which is then activated with the space bar, just as other components are 
activated with the space bar.  (but, I agree that this is out of scope for 3.3!)

Comment 5 akemr 2001-11-20 08:37:46 UTC
*** Issue 17313 has been marked as a duplicate of this issue. ***
Comment 6 Chris Ledantec 2001-11-20 08:51:55 UTC
agreed.
Comment 7 Marek Grummich 2002-07-22 08:45:02 UTC
Target milestone was changed from '3.4' to TBD.
Comment 8 Marek Grummich 2002-07-22 09:17:58 UTC
Target milestone was changed from '3.4' to TBD.
Comment 9 akemr 2002-08-01 09:25:39 UTC
Maybe this could be closed because of new Ivan's implementation of
error highlighting..
Comment 10 Chris Ledantec 2002-08-01 13:21:07 UTC
does the new implementation provide the behavior described here? if
yes then close the bug.
Comment 11 Marian Mirilovic 2002-12-06 17:14:28 UTC
reassigne to Tim, new owner of terminal emulator
Comment 12 Marian Mirilovic 2006-09-25 10:50:25 UTC
The core team has not been responsible for terminal emulator for long time, so
reassigne all opened issues to responsible person.
Comment 13 ivan 2008-10-22 09:50:34 UTC
The overall issue peratained to the days when output was based on Term,
but a lot of water has passed under that bridge.

This is likely still an issue in the re-introduction of Term
where we need to pay more attention to keyboard navigability 
between hyperlinks.
Comment 14 ivan 2008-10-22 10:02:26 UTC
*** Issue 20522 has been marked as a duplicate of this issue. ***