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 30979 - Aggressive focus grabbing (in dbx console)
Summary: Aggressive focus grabbing (in dbx console)
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: Sun Solaris
: P2 blocker (vote)
Assignee: mslama
URL:
Keywords: FOCUS
Depends on:
Blocks:
 
Reported: 2003-02-12 03:21 UTC by ivan
Modified: 2008-12-23 09:52 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Patch fixes focues event handling, place to lib/patches (86.66 KB, application/octet-stream)
2003-11-12 16:00 UTC, mslama
Details
Diff of new patch (11.08 KB, patch)
2003-12-15 13:39 UTC, mslama
Details | Diff
Binary patch, place to lib/patches (85.48 KB, application/octet-stream)
2003-12-15 13:40 UTC, mslama
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ivan 2003-02-12 03:21:27 UTC
I've got a dbx running in a Term docked into the
OW. As I type 'step', 'cont' or whatever
the editors PC glyph advances. All of this is
fine except that the editor grabs focus away
from the output window and I have to move
the mouse around before I can type 'step' 
or any other dbx command again.

This only happens in MDI mode.
Comment 1 Martin Roskanin 2003-02-12 10:27:19 UTC
It looks like the focus problem in core
Comment 2 Jan Lahoda 2003-02-12 10:34:56 UTC
->windowing system.
Comment 3 mslama 2003-02-13 10:42:19 UTC
How to run dbx in term? I am on Linux. (If necessary I can move to
Solaris.)
Comment 4 Marian Mirilovic 2003-05-16 08:14:51 UTC
gordonp:

Please do not change target milestone !!!
You can ask owner of issue to fix them for release , but not chahnge
TM by yourself. IMHO: it's too late to fix some non-stopper issue for
3.5 :(
Comment 5 _ gordonp 2003-05-16 14:25:31 UTC
Please check with Arseniy. The Rainier release will
be based on 3.5'R' and will need this problem fixed.
I don't really care what the Target Milestone field
says but we will need a fix in the 3.5 codebase.

RE will be creating a "rainier" branch just as soon
as release35 has been completely frozen.
Comment 6 Marian Mirilovic 2003-05-16 14:57:12 UTC
Gordon:
Yes, we know about it, each issue with keyword RAINIER will be fixed
for that release. 
 
Maybe we need new target milestone for RAINIER.
Comment 7 _ gordonp 2003-05-16 15:07:17 UTC
Possibly. One of the problems is that some of these
fixes will need to go into 2 codebases. Not just the
rainier branch but also into a ``current'' branch
(either the trunk or prj40).
Comment 8 ivan 2003-05-16 21:38:51 UTC
relax guys!
For one thing I haven't seen this happenin a long time,
so I believe it has been "magically" fixed. 

I'd still like someone who undertands focus in NB a bit
better to look into the existing code and see whether
there is a possibility of this happening under certain
situations.
Comment 9 mslama 2003-05-20 09:26:59 UTC
Good to hear that. It is very difficult to verify from code that focus
management is working as 'expected'. In addition I do not know who was
responsible for grabbing focus before. Usually I trace all request
focus in java.awt.Component.requestFocusHelper(). It is sufficient.
Sometimes it is necessary to go more deeply into code if I want to
find where given FOCUS_GAINED/FOCUS_LOST event comes from because
these events can be recreated by AWT in
java.awt.DefaultKeyboardFocusManager or java.awt.KeyboardFocusManager.
I mark this issue as WORKSFORME. Please reopen if it happens again.
Comment 10 Lukas Hasik 2003-08-18 09:33:55 UTC
verifying...
Comment 11 ivan 2003-08-25 00:43:24 UTC
Sorry guys. It's back.
It happenned in a "fresh" userdir.

How to go about diagnosing this?
Maybe we should use this bug as an excuse to finally have a system
of getting our stuff to prague and having someone there be
responsible for it?
Alternatively I could find the place that grabs the focus and
feed the info back to you? Except thatI"m not sure what's
the best way for this. A Bpt on requestFocusHelper? THat'll
be too manybpts. A stack dump in a modified version of AWT code?
How do you guys do dthis exactly?
Comment 12 mslama 2003-09-02 11:02:00 UTC
Please could give me more info? What exactly build, OS, JDK? Yes one
way how to find hwo requests focus is to add logging to
java.awt.Component.requestFocusHelper(). (In some cases it need not be
enough because some FOCUS_GAINED events can be created in awt as
result of some previous call of requestFocus(). Anyway it is good
first step. If it is not enough eg. there is no direct requestFocus()
call next step is to patch constructor of FocusEvent to find where
exactly given FOCUS_GAINED avent comes from and where whole chain starts.

To save you from such tricky investigation please provide me with
steps how to reproduce it. Of course you can make first step with
patching java.awt.Component.requestHelper() in JDK.
Comment 13 mslama 2003-10-01 08:54:21 UTC
Ivan please read my last comment and respond. Thanks.
Comment 14 ivan 2003-10-01 21:22:30 UTC
I have not discvered a specific set of steps that leads to
the problem, although we get reports of it often.

I have a plan to write a reproducible testcase 
involing a little application running internally and
manipulating the editor API's but I haven't been able to
execute on this plan yet.

If you have access to our "stuff" then I"ll furnish you with 
more information.
Comment 15 Lukas Hasik 2003-10-14 10:48:19 UTC
rainier, jdk 1.4.2, MDI

steps to reproduce:
1, have a c file compiled with -g option
2, Debug->Start Session->Load program and choose the executable
3, IDE switchs to Debugging WS, OW w/ dbx console opens

[note 1] where is focus now ? No window is highlighted.
[note 2] if you move mouse above OW (don't click just move) you can
type into dbx console.

4, type 'step' in OW 
5, focus is back in Editor

[note 3] if you click back to OW the focus stays in OW forever

6, type 'exit' in OW -> dbx is finished

[note 4] get focus to Editor (click). If you move mouse over dbx
console(OW) then you can type in OW (strange, isn't it?) and Editor is
still highlighted.

Ivan, could you confirm that this above is behaviour that you are
reporting ? thanks.


and more info. The 'Process Output' grabs the focus the same way as
dbx console. Just move mouse over it and you can type. I wasn't able
to reproduce it with NB40dev or NB35. Looks like not Editor but OW
grabs focus. Focus follow mouse has no impact on this - I was able to
reproduce w/o the ffm.
Comment 16 ivan 2003-10-14 21:10:16 UTC
On notes 2,4 the termulator is probably set to focus-follows mouse.
On step 5, yes this is the main characteristic of the symptom, but ...
On note 3, that's not what I see. further commands will shift focus 
           to editor over and over.
On "more info", terminalemulator has an API for choosing focus type
and is probably not well integrated with other focus mechanisms
and might be ignoring the desktops focus policy.
Comment 17 _ ttran 2003-10-20 20:40:49 UTC
> On notes 2,4 the termulator is probably set to focus-follows mouse.

Ivan, does the termulator indeed _intentionally_ mess with the focus
this way?
Comment 18 ivan 2003-10-20 20:54:11 UTC
Strictly speaking yes, but until Lukases comments here I've never
seen that setting interfere. If I switch to MDI or click2type
the OW behaves as expected. I figured the input events to the
termulator get masked by the container in some way; and if the
container acts as expected Term ends up working. 

This is under x-windows; 'mwm'.

I'm planning a "batch" of term work in before Dec so I've jotted this
down as an issue to follow upon as well.
Comment 19 mslama 2003-11-11 10:06:08 UTC
I checked again now (running remotely from Linux on Solaris 9) and it
looks like I am able to reproduce it:
1.Start debugger.
2.Set focus in editor.
3.Move mouse to Output Window [Debugger Console].
4.Focus is now inside Debugger Console but because there is no
FOCUS_GAINED event winsys still thinks focus is inside Editor. Editor
frame is blue (activated) and Output Window frame is grey (not activated).
5.Write step and press Enter in console.
6.Focus gets back to Editor!!! You can see cursor.

It looks like FOCUS_GAINED event is somehow consumed and does not get
to winsys to update its state correctly.

I recommend to switch off focus follow mouse behavior of terminal
emulator and check again. It looks like it breaks focus handling of
winsys: Focus is not where it is expected by winsys.
Comment 20 mslama 2003-11-11 10:28:56 UTC
I set click_to_type to true (commented out setter) and focus stays in
Debugger Console it is not grabbed by Editor as it was when focus
follows mouse in terminal emulator. So this would solve this issue. (I
encountered problem: I must click twice to Debugger Console to be able
to write there.) Question: Is it possible to switch off focus follows
mouse inside terminal emulator?
Comment 21 mslama 2003-11-11 11:23:47 UTC
I investigated why Output Window is not properly activated when
terminal emulator request focus on itself when mouse cursor enters
Debugger Console. I found it is bug in winsys focus handling:
FOCUS_GAINED event is processed in winsys but is ignored. The behavior
described above is consequence of this incorrect focus handling. 

However any change in focus handling inside winsys at this stage is
risky. (New winsys should solve such issues - focus handling is
designed). So if it is acceptable to limit functionality of terminal
emulator namely disable it inner focus follows mouse emulation I
highly recommend to fix it by that way. Ivan and Gordon what is your
opinion?
Comment 22 _ gordonp 2003-11-11 18:02:12 UTC
What exactly is the effect of turning off focus-follows-mouse? Does it
mean I always have to click to activate the Debugger Console? Thats
what it sounds like and I find that a serious problem.

I think I'd prefer the winsys bug fixed. At least give us a chance to
test with that bug fixed. There are so many focus bugs right now we
are already concerned that it makes our product extremely difficult
to use. Suggesting one shouldn't be fixed seems counter-productive. If
fixing it has adverse side-affects we've got enough time left to find
them and decide if they are worse than what we have now. The current
behavior is pretty serious. Users end up typing things like "step"
or "next" into their sources. While they can delete these words if
they see them (hopefully they will) it makes the product look very
bad!
Comment 23 ivan 2003-11-11 20:28:54 UTC
Thanks for the investigation.
I"ll be swithing to working on teh termulator next week.
and will thouroughly explore whether termulator really needs to
do it's own focus mgmt (among other things).
Comment 24 mslama 2003-11-12 15:59:45 UTC
I prepared patch. It fixes FOCUS_GAINED event handling in container. I
tested it both in MDI and SDI and did not find any problem so far. But
as I said it is potentialy dangerous change. (FOCUS_GAINED event was
incorrectly ignored when target frame was not activated or selected
and newly focused component was not different. Both conditions was
true so event was ignored.)
Comment 25 mslama 2003-11-12 16:00:47 UTC
Created attachment 12128 [details]
Patch fixes focues event handling, place to lib/patches
Comment 26 mslama 2003-11-12 16:10:26 UTC
> What exactly is the effect of turning off focus-follows-mouse? Does it
> mean I always have to click to activate the Debugger Console? Thats
> what it sounds like and I find that a serious problem.

Yes. Exactly in MDI term emulates OS WM focus follows mouse but only
for itself ie. term component (area) NOT for other components like
editors in Source Editors. In SDI when OS WM 'focus follows mouse'
mode is enabled it works consistently for all native windows. In MDI
there are JInternalFrames inside main window.

Comment 27 ivan 2003-11-12 22:27:38 UTC
Gordon: ... serious problem.
Marek: Yes exactly.

Slow down guys.
Terminal emulator has a setting for doing it's own focus mgmt.
If it's set to follow-mouse it will detect mouse entries and
ask for focus. Otherwise it will listen to mouse clicks and
do the same. 
IT SHOULD NOT DO THIS. At least in principle.
I do not remember what posessed me to implement it this way
in the first place. Next week I"ll work on this and turn that
code off and see what happens. It needs to be turned off, 
not switched from one mode to another. Of course
then we might run into a whole host of other "doesn't work"
situations.

Comment 28 ivan 2003-11-27 00:05:51 UTC
After some more investigating ... to make a long story short,

a) Components are supposed to do their own conversion of gestures to
requestFocus(). So the stuff stays in.
b) Historical usability issues make it imperative that in SDI
mode Term stays FFM. That works fine. 
In MDI C2T is the rule so having Term be C2T makes sense at first
approximation. 
We can switch Terms focus policy on this basis.
question: should we do this just for our windows or for OW 
managed windows as well?
I think we can avoid the patch.
Comment 29 ivan 2003-11-27 01:39:59 UTC
Some complications with MDI/ClickToType

- "weak" extra click effect
  MDI 3.5, trunk
  Clicking OW tabs or banner doesn't give focus to visible
sub-component.
  You have to go click into it.
  
- "strong" extra click effect
  MDI 3.5
  If you click into the term itself it and it's containers should get
  focus. This works in trunk.
  In 3.5 you have to click twice. The first time focus goes to the
  banner, the second time to the term.

The patch doesn't affect either of these.
The weak effect is tolerable, the strong one isn't.

Also I'm puzzled why Term being C2T should make a difference to
the original bug, supposedly fixed by the patch. Term will
call requestFocus() no matter what mode it's in so the dropped
FOCUS_GAINED should have manifestation in either case.
Comment 30 ivan 2003-12-10 21:19:09 UTC
good and bad news:
good: We've accepted Mareks fix because it solves the immediate
      problem. My attempts to tailor Terms focus policy depending
      on MDI/SDI didn't go aywhere because there's no open API to
      tell me MDI vs SDI.
 bad: There seems to be a second bug with the same symptoms.
      If in the course of stepping or whatever command in dbx cmd
      window you end up in a new file, when the editor pops up a new
      Tab, it grabs the focus!
      
Comment 31 mslama 2003-12-11 09:13:04 UTC
Why do you need to emulate in term 'focus follows mouse' at all? It is
responsibility of OS WM. If not we would have to do such things in all
components not just in term. So IMO you need not to find MDI?SDI state
just remove 'FFM' emulation from term completely. Or am I missing
anything?
Comment 32 mslama 2003-12-11 09:19:05 UTC
Regarding bad news: When editor opens new tab (new editor) it is by
design that focus is transferred to newly opened editor. It is the
same as you for example double click some node in Filesystem view to
open editor. Focus is transferred from Explorer to Editor.

Regarding 'strong' extra click effect you should file new issue so it
will be investigated.
Comment 33 ivan 2003-12-12 01:19:34 UTC
Re: Why do you need to emulate in term 'focus follows mouse' at all?

In the past two debugger guis that we've had, Workshop and dbxtool,
users expected the dbx console and program io windows to
be FFM _even_ when they are embedded. This is a bit unusual because
embedded "text" widgets are always C2T within a window. I speculate
that one gets used to a "term" being FFM and this expectation,
the neurons that fire, are still strong even when the term is
embedded.

Re: It is responsibility of OS WM.

Not according to my understanding. The few widgets I've looked at
are responsible for taking a user gesture and converting it to
a requestFocus().
Also, terminalemulators break the rules and have historically always
been special cased.  For example in OpenLook/xview the pty-based
"TERM"
mode of the textwidget was undocumented because it didn't fit the
norm.
In DtTerm you have this:

_DtTermPrimActionEnter(Widget w, XEvent *event,
        String *params, Cardinal *num_params)
{
    ...
    if ((_XmGetFocusPolicy(w) != XmEXPLICIT) && ... ) {
        tw->term.hasFocus = True;
        _DtTermPrimCursorChangeFocus(w);
    }
    ...
}

This is the implementation of FFM and is using an internal
_undocumented_ motif call, _Xm! (Apparenlty in newer Motif
it is "supported" as XmeGetFocusPolicy).

Setting the Term self-policy strictly to C2T has these effects:
- In MDI it works reasonably well, except for the "strong" extra
  click effect.
- In SDI when WM is C2T I expect it would work well, although I
  haven't tested it nor do I believeit is predominant.
- In SDI when Wm is FFM it does sort-of cooperate with the WM.
  For example you click in it once, then moving the mouse in
  and out of the OW doesn't steal the focus. But if you change Tabs,
  click into the runtime window, click into any other window you have
  to click back into the Term, so it's not truly FFM.

Swing offers no equivalent of XmeGetFocusPolicy so based on
the above three scenarios I tried to mimic it by looking at
MDI vs SDI as an approximation, but there's no open API for that.
I"m still tempted to use the non-open apis.

Perhaps the focus mode should be exposed in the options dialog?

Re: bad news

First some other email from Marek:
> It is possible they will want to fix new problem with 'mouse click'
> to focus term in Rainier. Waiting for Ivan response.

I"m not sure if this comment relates to the "bad news", but
I don't see that this makes a difference. No matter what mode Term
is in, stepping into a previously unopened file steals the focus.
I understand the logic based on double-clicking in the file explorer,
but it still leaves the fact that it makes our debugger broken.
I also understand that there is unlikley to be an easy solution to
this since it ultimately requires the editor to know who and why a
file was opened.
Comment 34 mslama 2003-12-15 09:15:26 UTC
Ivan Do I understand it correctly that I should check/prepare patch
for window system to fix this issue?
Comment 35 mslama 2003-12-15 13:39:13 UTC
I revised previous patch for winsys. Processing FOCUS_GAINED event is
fixed. Modified MultiTabbedContainerImpl, SplitContainerImpl,
DefaultContainerImpl. Please test and let me know if I should commit
fix to branch.
Comment 36 mslama 2003-12-15 13:39:55 UTC
Created attachment 12574 [details]
Diff of new patch
Comment 37 mslama 2003-12-15 13:40:42 UTC
Created attachment 12575 [details]
Binary patch, place to lib/patches
Comment 38 ivan 2003-12-16 01:11:45 UTC
Marek Slama 2003-12-15 01:15 PST:
> Ivan Do I understand it correctly that I should check/prepare patch
> for window system to fix this issue?
                           ^^^^
Sorry, which issue specifically?
You mention FOCUS_GAINED but that doesn't translate to any user-level
symptoms for me.
Comment 39 mslama 2003-12-16 09:45:49 UTC
Sorry for net being clear. Correct handling of FOCUS_GAINED event is
necessary for internal FFM mode in term to work correctly ie. when
term calls requestFocus() its mode/window and TopComponent
(OutputTabTerm) is correctly activated/focused. It means that window
system knows about focus change and aggressive focus grabbing by
editor will not happen. So this fix will fix bad behaviour described
in this issue. Please let us know if it works. (I tested this together
with fixes of issue #32492 which should be present in next Rainier
build #35.) As I am on vacation from tomorrw I assign this issue to
Peter. 

Peter please as this fix will be tested commit this fix (diff is
attached) to branch 'release35R'. To be able to build core modules you
need following modules from this branch: ant core java libs nbbuild
openide xml. Then you can check that it is buildable from nbbuild eg.
ant all-core. Thanks.
Comment 40 ivan 2003-12-17 01:33:09 UTC
I don't get it, then what did the patch of
	 2003-11-12 08:00 PST ... attachment (id=12128)
        Patch fixes focues event handling, place to lib/patches
fix? 
I had verified it and it worked, so why do we need a second patch?
Comment 41 mslama 2003-12-17 07:57:29 UTC
Second patch is more refined to be less risky eventually. More
details: There is method
DefaultContainerImpl.reactivateSelectedComponent called from many
places. One place is also from componentFocusGained which processes
FOCUS_GAINED event. In reactivateSelectedComponent there is condition 
if (!isActivated()) return; I had to remove this condition so that
FOCUS_GAINED event is processed even in this case where term calls
requestFocus(). First patch removed this condition always. Second
patch removes this condition only when reactivateSelectedComponent is
called from componentFocusGained. It is done to keep minimum changes
in code to avoid breaking something else. To conclude: Second patch
does the same in this case but does not change behaviour in other
cases when reactivateSelectedComponent is called. So please to be sure
test second patch. I tested it and did not find any problem.
Comment 42 ivan 2003-12-17 22:43:24 UTC
OK, I'll verify the new patch as well, but
I"m more concerned about the "bad news". It
_is_ a big issue for us. What can we do about it?
Comment 43 ivan 2003-12-19 00:14:23 UTC
Hooray!
The 2nd patch fixes the "bad news" problem as well.
I don't see the editor grab focus even on new tabs.
I vote for integrating the fix into the code.
Thanks for sticking with us Marek.
Comment 44 Peter Zavadsky 2003-12-19 12:29:18 UTC
Marek isn't here now. He will be back after New Year (I guess).
He told me to integrate this if approved. Can I do it?
Comment 45 Lukas Hasik 2003-12-19 14:42:20 UTC
I tried the latest patch too.
Even if it seems to me a little bit weird to steal focus only in
debugger OW when you just move mouse cursor over it. I don't care if
it's your choice, Ivan. It works as requested now -> debugger OW has
still ffm behaviour but now it gets also activated.

From my point of view the patch do everything what Ivan asked for. I
didn't noticed any side effect (till now) and I didn't try opening new
file from OW 'cause simlply I don't know how.

Peter, go ahead and commit the patch to *release35R* branch and mark
this issue FIXED. 
Comment 46 _ ttran 2003-12-19 14:54:51 UTC
Peter, integrate the patch please, release35R branch.  Double check,
don't break the build.  Thx
Comment 47 Peter Zavadsky 2003-12-19 15:37:08 UTC
Applied the patch into [release35R]

Note: the diff of patch was incomplete, but after call with Marek it
was complished.

Checking in
core/src/org/netbeans/core/windows/frames/DefaultContainerImpl.java;
/cvs/core/src/org/netbeans/core/windows/frames/Attic/DefaultContainerImpl.java,v
 <--  DefaultContainerImpl.java
new revision: 1.75.2.1.10.1; previous revision: 1.75.2.1
done
Checking in
core/src/org/netbeans/core/windows/frames/MultiTabbedContainerImpl.java;
/cvs/core/src/org/netbeans/core/windows/frames/Attic/MultiTabbedContainerImpl.java,v
 <--  MultiTabbedContainerImpl.java
new revision: 1.57.2.1.16.2; previous revision: 1.57.2.1.16.1
done
Checking in
core/src/org/netbeans/core/windows/frames/SplitContainerImpl.java;
/cvs/core/src/org/netbeans/core/windows/frames/Attic/SplitContainerImpl.java,v
 <--  SplitContainerImpl.java
new revision: 1.104.30.2; previous revision: 1.104.30.1
done
Checking in
core/src/org/netbeans/core/windows/frames/TabHandlePopupListener.java;
/cvs/core/src/org/netbeans/core/windows/frames/Attic/TabHandlePopupListener.java,v
 <--  TabHandlePopupListener.java
new revision: 1.4.30.1; previous revision: 1.4
done
Processing log script arguments...
Mailing the commit message to cvs@core.netbeans.org (from
pzavadsky@netbeans.org)
Comment 48 Peter Zavadsky 2003-12-19 15:37:32 UTC
fixed
Comment 49 Marian Mirilovic 2004-03-15 15:28:18 UTC
Ivan,
could you verify this issue ? 

Thank in advance...
Comment 50 ivan 2004-03-15 20:03:07 UTC
verified