Community
Participate
Working Groups
When invoking WizardDialog.run(...) FocusOut events will be thrown for the focus Control when it is disabled. SWT will attempt to find the next control to set focus to when the focus control is disabled. This can cause multiple controls to receive focus, and therefore throw FocusOut events, when disabled during this process.
Created attachment 48676 [details] patch I included a JUnit for the change in the same package as WizardDialog. I wasn't able to locate the jface unit tests in CVS.
The patch in attachment 48676 [details] defers the disabling of the focus Control until all others are disabled. This allows for just one FocusOut. It will be for the control that has focus and will be restored focus after the runnable is executed.
Boris, in response to the IM last week if you run the JUnit that is in the patch without applying the patch for WizardDialog you'll see that the second button throws a FocusOut when dialog.run(...) is invoked. This should not occur as it didn't have focus when dialog.run(...) was invoked. If you need more of an example than the JUnit let me know and I'll whip up a snippet.
Bugfix and test released to HEAD >20060926.
I reverted the patch until we know more about FocusOut events from SWT.
The SWT fix on 20060927 fixed the issue on OS X. I tried to get Ubuntu running under Parallels on my MacBook Pro but I ran into issues with debugging in Eclipse so I've yet to narrow down the linux issue.
Boris and/or Brad: what's happening with this bug? it is targetted for M3 but it doesn't seem like it will be resolved in that timeframe.
Since I can't debug on Linux I won't be able to get a fix for M3.
Re-targetting to M4. Boris, should this bug be assigned to Brad?
(In reply to comment #9) > Re-targetting to M4. Boris, should this bug be assigned to Brad? Yes, why not. Brad, if you could ping me in the week after M3 is released, I can look at this on a Linux box again.
Moving to M5 (too late for M4 at this point)
This bug is still assigned to Brad, and is open with an incorrect target milestone. Did it get fixed? If not, it's probably too late to be changing the behavior for 3.3 now.
I don't believe it got fixed. Moving to 3.4.
It doesn't look like anything was done about this in 3.4 either. Clearing target milestone and moving back to ui inbox for further triage.
Matt, I believe Brad encountered this in a wizard that used data binding. Do you think this is a common case? Have you seen weird behaviour in wizards because of this?
After reading through the comments and reviewing the patch, I'm still fuzzy on what this bug is about. :/ Exactly what controls are losing focus inappropriately, when, and under what circumstances / uses?
OK, then you haven't seen a problem like this yet. :) Susan, do you think Brad's patch might have prevented the bug we had recently where typing a word containing the letter "c" in the filter field of the p2 update dialog ended up closing the dialog?
(In reply to comment #15) > Matt, I believe Brad encountered this in a wizard that used data binding. Do > you think this is a common case? Have you seen weird behaviour in wizards > because of this? > I apologize for being unresponsive. I haven't opened Eclipse in 6 months and these emails are getting filtered. This didn't have anything to do with data binding. I attached a patch which included a test case that demonstrated the issue. At this point I'm not sure if the issue remains and on what platforms.
Prakash is now responsible for watching bugs in the [Wizards] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
