Community
Participate
Working Groups
I20051214-0800 We found this when verifying bug 120656. Does not happen on WindowsXP. 1. open Quick Outline (Ctrl+O) 2. choose "Move" or "Resize" from view menu 3. move/resize 4. click into editor ==> key binding for Ctrl+O no longer working Tom: please clarify here: is it just Ctrl+O or all key bindings.
Veronika: I believe this is the problem you mentioned at lunch. The Java context is not active when this happens. It is deactivated immediately before the outline view opens. (AbstractInformationControl.createTitleMenuArea). It is then never re-activated when the popup closes. It doesn't seem like the ContextService is doing anything wrong. Can you guys take a look at your end of this?
The problem I mentioned at lunch was on motif and it is not recreated by these steps. However, I was able to recreate the problem in this bug report on GTK. Who did you mean by "you guys"?
Veronika: Okay, perhaps you should open a separate bug then. I meant Zurich, whether that be Platform/Text, JDT/Text or JDT/UI.
We restore the scope in widgetDisposed. Since this works under XP I assume some eventing problem in the PopupDialog.
I think it's a permutation of bug #115785 - Quick dialogs don't appear after having used the menu. This bug was originally reported on Windows and fix. I believe that fixing bug #120656 has reintroduced the problem on Linux. There are internal flags in PopupDialog which control how shell deactivate events are handled, and these events come at different times (and different orders) across platforms for things like: - submenus - tracker rectangles - child shells opening - etc. So far each fix for these bugs has tended to introduce a less severe problem on some other platform. And each fix must be validated by all platforms for risk of regressing the others. Unfortunately my Linux box is not booting and won't be repaired this week. So I see that we either: 1) document it as an M4 problem and I'll look at it for M5 2 ) Dani could try the workaround he used in bug #115785 and see if it works around this one. (see bug #115785 comment #2)
The workaround Dani used before was in AbstractInformationControl. Probably would work again.... Sorry, Dani. I obviously need to aggregate the test cases from all these event flow bugs so that one bug doesn't reintroduce a new flavor of another. /** * {@inheritDoc} */ public void setVisible(boolean visible) { if (visible) open(); else // FIXME: workaround for https://bugs.eclipse.org/bugs/show_bug.cgi?id=115785 dispose(); }
Dani just tested the workaround on Windows XP and Linux. Looks good. I just tested on the Mac. Looks good. There are no other clients in the SDK that use the popup dialog menu feature, so this should be a decent workaround for M4. I will reinvestigate for M5. cc'ing Dirk - I think you are using the menu feature in some of your other experiments....you will need this kind of workaround...
Dani has released the workaround for I20051214-2000
Verified in I20051214-2000 that the workaround works on WindowsXP and Linux-GTK+.
Susan, thanks for CCing me. Indeed I am using the Popup dialog and it is bound to a key board short cut. However the short cut lives in the Global Scope. Do you think this will result in the same problem.
You should be fine with respect to keys if you aren't manipulating the key binding scopes in your popup. It's possible you would have cleanup issues or possible leaks caused by this problem, but only if you also implement some of your own popup hiding behavior as AbstractInformationControl does. The scenario is on Linux only. The user opens the move/resize menu in the upper right hand corner, performs a move or resize, and then clicks in the Java editor. Normally the dialog should close, but due to the bug, the shell deactivate event is missed. For a simple client, the effect is that the dialog would just hang open. User sees the bug (dialog didn't close) and can force it closed by hitting Esc, etc. That would be the whole story. But in the case of AbstractInformationControl, when the user clicks in the editor, the editor calls API to hide the dialog (vs. close it). The dialog hides, but is still alive. And since that particular dialog replaced the editor's key binding scopes with the window scope when it opened, the editor key bindings are now lost. The AbstractInformationControl workaround is to dispose the dialog when they hide it, so that the scopes are restored.
Fix must test this case, the cases from #120656, and #123392. Once fixed, all of these cases need to be documented in a manual test description.
Tom and/or Dani. I am not seeing the behavior described here. I am running I20060105 + the latest JDT UI and everything that had to be dragged in along with it for it to compile. I then removed the workaround in AbstractInformationControl (commented out the dispose() call in AbstractInformationControl#setVisible). What you described: 1. open Quick Outline (Ctrl+O) 2. choose "Move" or "Resize" from view menu 3. move/resize 4. click into editor ==> key binding for Ctrl+O no longer working What I see: 1. open Quick Outline (Ctrl+O) 2. choose "Move" or "Resize" from view menu 3. move/resize 4. click into editor ==> popup does not dismiss. Must be closed using Esc or the close box. Can you please remove the workaround in AbstractInformationControl and let me know if you are still seeing the originally reported problem or the popup staying open?
> I then removed the workaround in >AbstractInformationControl (commented out the dispose() call in >AbstractInformationControl#setVisible). The code must also handle the 'false' case, you can find the correct code in the revision history (1.38): public void setVisible(boolean visible) { if (visible) open(); else { saveDialogBounds(getShell()); getShell().setVisible(false); } } We verified that the bug is still there when using that code.
That makes sense, thanks.
Fixed >20050117. Test process and scenarios described in bug #123392. Dani, you may remove the workaround.
Thanks. I will remove the workaround after next weeks I-build.
this is actually a duplicate of #123392 but was left open to track workaround. Marked verified (rather than reopen/resolve/duplicate)
