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 30536 - F12 & S-F12 work only on last-used output window
Summary: F12 & S-F12 work only on last-used output window
Alias: None
Product: cnd
Classification: Unclassified
Component: Terminalemulator (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: ivan
Keywords: A11Y, UI
Depends on: 28297
Blocks: 34908
  Show dependency tree
Reported: 2003-01-30 21:25 UTC by Jesse Glick
Modified: 2010-05-08 07:18 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-01-30 21:25:02 UTC
Search filesystems for some text string in Java
sources and click Show Details to display hits in
the Output Window. Close the search dialog. Now
F12 and S-F12 work to jump between lines - great!

In one of the files you are editing, make some
change and recompile. Compiler tab appears; if
there are errors/deprecations, they are
hyperlinked and F12 and S-F12 jump between them -
again fine.

When you are done with this file and want to work
on the next search, you give focus back to the
Search Results tab, and click F12. Doesn't work -
still tries to go between compiler errors, if any.

IMHO F12 and S-F12 should always operate on the
last-focussed output tab, keeping track of the
current item on a per-tab basis.
Comment 1 Jesse Glick 2003-01-30 21:25:46 UTC
Impacts KB navigability, e.g. of large search results.
Comment 2 Peter Zavadsky 2003-01-31 12:35:47 UTC
This shows that NextOutJumpAction as a global one is not working fine.

I suggest to make it really context aware, i.e. override its
getActionMapKey, and that provided key to use in the output component
actionMap to delegate to such action which will work according that
component context (i.e. in search resutls make what does its performer
and in compiler what does its performer).

Look at

I'm not much in it, so if there are some problems with it, please let
me know.
Comment 3 Jesse Glick 2003-01-31 18:14:21 UTC
Peter, I don't think that can work. It is not enough to bind these
keys in the output window. They can be called from the editor window
too and expected to work with the last-selected output window.

See also comments in issue #30535. That issue suggests a possible need
for a more general, and API-accessible, solution to the prev/next jump
action design. However *this* issue can be solved w/o any API change,
since I am referring only to the real Output Window: Search Results
just uses IOProvider etc. as usual, meaning the component is
implemented in core/output and can know what the current output window
tab is.

Possible solution to *both* issues:

1. Some API (openide/io?) will define the action map names "next-link"
and "previous-link" (e.g.); it need not do anything else except
document them

2. Global KB bindings for F12 & S-F12 changed to be bindings for these
names, like an input map (is this possible yet?!)

3. OutputTabTerm will put something in its TopComponent lookup that
will be its list of known hyperlinks - exact content acc. to private
impl. in core/output 

4. The actions in core/output will *not* be CallbackSystemAction's;
just plain AbstractAction's, I guess, implementing ContextAwareAction;
they will ask the context for the stuff that OutputTabTerm put into
its lookup, and jump around between links in that tab only

5. OutputTabTerm will bind "next-link" and "previous-link" in its
action map to these actions

6. Task List suggestions view (etc.) will bind these action names to
its own analogous actions

7. CloneableEditor will bind these action names to proxies which
listen to changes in the active top component, updating their
delegates to be that of the last top component to be activated which
had bindings for their own names

Then pressing F12 & S-F12 on any output-type component will always
navigate within it. These keys from the editor will work with the last
selected output-type component.

The only part I am not sure about is step 2. Currently shortcuts are
bound directly to action implementations. We need them bound instead
to action names, like Swing input maps do. In this case we can
probably hack around it by binding them to special proxy actions which
somehow find the focus owner active at the time the action was invoked
(acc. to the action event? does this work?), look up the real action
according to the action map of that component, and delegate to it with
the same action event and action context.
Comment 4 Jesse Glick 2003-01-31 18:26:34 UTC
Variant: collapse #2 & #7, so that the global KB shortcut bindings
(could be defined in *any* module, but probably core/output) are just
bound to proxy actions (maybe two instances of the same class). These
take their action event and obtain the focus owner from it. (Details
TBD) If that owner provides a binding for the action in its action
map, it is run directly, with context taken from the closest enclosing
Lookup.Provider in the component hierarchy as usual. If there is no
such binding available, then the proxy action has also been keeping a
listener active on TopComponent's, waiting for selection of a
component with a binding for its own name; if one appears, it keeps a
weak reference to that component. When next invoked on a component
with no binding of its own, it goes back to the last output component
(if it still exists, is open, is showing, etc.), asks it again for its
binding, and runs it (again with the usual action context taken from

More or less the same effect, but has the advantage that you continue
to define the physical KB shortcut in one place only, making user
customizations of this shortcut easier.

Probably want to write this proxy action class as neutrally as
possible and just create two instances parametrized by action name
("next-link" etc.) using methodvalue in core/output layer. That way if
this kind of thing works well, we could easily make it into an SPI for
some future Actions rewrite - a general proxy action that operates on
either the selected component, if possible, else on the last selected
top component to define it.
Comment 5 Peter Zavadsky 2003-02-03 09:49:12 UTC
Yes, I think the 'Proxy action'-solution from Jesses last comment is
the right way for this kind of problem.

Well, so to not forget about the support ProxyAction class I create a
task for it.
When also another Action support clases (NodeAction, CookieAction)
will be written it should be between them.

Comment 6 Jesse Glick 2003-02-03 14:28:52 UTC
Of course "ProxyAction" is not a great name for such a thing, since it
has more specific behavior than just proxying. No suggestions re. name
for now.
Comment 7 _ tboudreau 2004-04-19 14:06:22 UTC
Reassigning to Marek, new owner of output window and help system
Comment 8 Marian Mirilovic 2006-09-25 10:50:30 UTC
The core team has not been responsible for terminal emulator for long time, so
reassigne all opened issues to responsible person.
Comment 9 Lukas Hasik 2008-12-21 21:08:20 UTC
moving opened bugs on terminal emulator to terminalemulator/code as the core
component will be closed soon -
Comment 10 ivan 2010-05-08 07:18:56 UTC
This all looks like water under the bridge.
For one thing F12 is no longer a standard NB accelerator.
For another output windows was rewritten.

The recently introduced terminal based IO _does_ have issues with
handling global NB accelerators (see bug #185483) but that
doesn't seem to be the issue here.