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.
Summary: | Aggressive focus grabbing (in dbx console) | ||
---|---|---|---|
Product: | platform | Reporter: | ivan <ivan> |
Component: | Window System | Assignee: | mslama <mslama> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | gordonp, jchalupa, lhasik, mmirilovic, ttran |
Priority: | P2 | Keywords: | FOCUS |
Version: | 3.x | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Patch fixes focues event handling, place to lib/patches
Diff of new patch Binary patch, place to lib/patches |
Description
ivan
2003-02-12 03:21:27 UTC
It looks like the focus problem in core ->windowing system. How to run dbx in term? I am on Linux. (If necessary I can move to Solaris.) 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 :( 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. 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. 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). 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. 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. verifying... 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? 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. Ivan please read my last comment and respond. Thanks. 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. 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. 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. > 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?
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. 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. 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? 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? 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! 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). 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.) Created attachment 12128 [details]
Patch fixes focues event handling, place to lib/patches
> 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.
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. 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. 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. 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! 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? 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. 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.
Ivan Do I understand it correctly that I should check/prepare patch for window system to fix this issue? 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. Created attachment 12574 [details]
Diff of new patch
Created attachment 12575 [details]
Binary patch, place to lib/patches
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.
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. 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? 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. 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? 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. 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? 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. Peter, integrate the patch please, release35R branch. Double check, don't break the build. Thx 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) fixed Ivan, could you verify this issue ? Thank in advance... verified |