*** Issue 24878 has been marked as a duplicate of this issue. ***

This is general problem of UI, not javadoc itself. The same case is
e.g. Search results dialog.

It works OK for me on Linux using MDI... just switch back to the main
window, e.g. Alt-TAB. Currently it seems I cannot get KB focus on the
main window with the ACT open as a separate window, but I have had
similar problems in general with the window system, and it may just be
a problem with interactions with my window manager. Could you explain
exactly what the problem for you is?

Perhaps the window system should front the main window if focus is
requested on a component inside the main window?

My problem is exactly described in your last sentence. Usually ACT
covers my editor window, so when I hit View Source actually nothing
happens, of course that editor is scrolled to the correct line, but
nobody can see that and I would expect that if I hit View Source I
will view source and not search for editor window by Alt+TAB. It
applies for any other search, find of view dialogs.

So it sounds to me like this may be a window system issue then.
Javadoc developers, what is actually called when View Source is
pressed? E.g. TopComponent.requestFocus()?

            OpenCookie oc = ((OpenCookie)srcElement.getCookie(
OpenCookie.class ));
            oc.open();

The rule is:

If action is invoked from top component (e.g. "View Source" from Auto
Comment Tool) and the result of the action is displayed in different
view then such view should be brought to front. It means that if the
view that presents the result of the action is in Main Window (MDI)
then Main Window should be brought to front too (not just view inside
Main Window).

Is it possible to implement it in core or on module side? If it is, I
would like to test the patch before applying to check possible side
effects.

Marek, please evaluate.

I am not sure who should fix this but it belongs to javadoc module. If
you think that ui evaluation is not correct reassign back, thank you.

Set target milestone to TBD

This bug is reported in version <= 3.4dev and still not fixed. Due to that it
forbids the release candidate for 3.4 to be promoted. Are you aware of that and
are you intensively working on the fix? If not, you should consider some
corrective action.

Decreasing priority since this is not stopper for release34. By higher
priority I wanted to point out that mixture of "native" top components
and internal frames do not cooperate very well, although it's more
general problem.

I think it is a core issue: during the execution,
CloneableTopComponent.requestVisible() and requestFocus() are called
(in that order).
If some other method should be called to bring the TC to front please
reassign back with an advice.

I would say that requestFocus for TopComponent shouldn't bring its
window to front. But it seems the javadoc in TopComponent claims that :-(.
Marek, do you know how it should work?

Anyway, the possible advice could be, to add following snippet after
the requestFocus call:

Window w = SwingUtilities.getWindowAncestor(tc);
if(w != null) {
    w.toFront();
}

Probably it is necessary to schedule that snippet later into AWT in
case you aren't in AWT already (open isn't synchronous if you aren't
in AWT already).

No. Forget about Peter's suggestion. I will check it. When you call
TopComponent.requestFocus() it call also JInternalFrame.setSelected()
and it shoudl front frame at least in MDI. I take this issue and
investigate it.

TopComponent.requestVisible() is meant if you want to front component
in JTabbedPane but NOT assign focus to it. => using both
requestFocus() and requestVisible() at the same time on the same
component is redundant.

Again problem with transferring focus/fronting windows. It is never
ending story. UI has some view how it should work and OS Window
Managers has their own (and unfortunately there is more than one OS
WM) so it impossible to infy these views/expectations. The main
problem here is that there are mixed MDI desktop and separate native
windows (SDI part). 

Unfortunately JDK Component.requestFocus() does not guarantee focus
transfer when focus should be transferred between native windows.
Actualy it works (cross window focus transfer) on Window but not on X
Windows - Linux).

If desktop is pure SDI we use java.awt.Window.toFront() in
TopFrameTypeImpl to transfer focus between native SDI windows AND
front target windows.

Problem here is mixture of SDI window (ACT) and main MDI window. In
such case there is no call of toFront() (when focus should be
transferred from separate native window to main app window. It needs 
call of toFront() on main window as Peter suggested.

Created attachment 10623 [details]
Diff of patch

Created attachment 10624 [details]
Binary patch

Patch is for dev build. Place it to
$NBDIR/modules/patches/org-netbeans-core-windows. Fix calls toFont()
on main window when focus is requested for Mode with internal or
desktop frame (ie.frame inside of main window) AND main window is NOT
focused.

Fixed in main trunk as described above.

Modified:
core/windows/src/org/netbeans/core/windows/ModeImpl.java r.1.4

Verified on Win XP. I will verify it also on X.

*** Issue 35922 has been marked as a duplicate of this issue. ***

issue doesn't apply to new window system - verified