Community
Participate
Working Groups
Created attachment 177528 [details] Screenshot depicting the problem in question. M20100825-0800 1. Close all editors if any are open. 2. Detach the 'Package Explorer' view. 3. Activate the 'Problems' view in the original workbench window. 4. Activate the detached 'Package Explorer' view. 5. You should see a 'Source' menu in the workbench window. 6. Try to click the 'Source' menu. 7. You will end up getting the 'Navigate' menu.
This is a regression! It works in 3.4... The issue here seems to be the activation handling which activates some part *within* the main window when the shell activates...this ends up resulting in the menu being re-evaluated... Not sure to whom it should go (DW's, Commands, Workbench?) but I'll tag it for 3.7 so it won't get lost...
I wasn't following the repro instructions exactly (no editors open!), this problem exists in 3.4 (it's not a regression...).
Yeah, I also don't see a difference between 3.4.2 and HEAD. It works in a few limited scenarios, but I guess that's more by chance (e.g. when the active view in the main window doesn't have a selection -- e.g. the empty Type Hierarchy view). The underlying problem is that the focus and goes to the main window. This changes the current selection and therefore makes all selection-dependent actions unusable (menus, main toolbar buttons).
*** Bug 324074 has been marked as a duplicate of this bug. ***
I'll send this to 'Workbench' since its an activation issue...
Fixing that by allowing the actions in the main window to go to the detached view would be unexpected because at the end of the action you have the main window with its recent active part in focus but the last action executed on the selection from the detached view. A simpler approach could be to disable the actions in the main window if the detached view has focus. Important is to not hide/show menus and toolbar items. With such an approach bug 324074 is not a dup and becomes invalid again.
*** Bug 326987 has been marked as a duplicate of this bug. ***
The actual issue here is that we change the active part when the main shell gets activated... This is the result of an SWT.Activate listener in the PartPane which calls 'requestActivation', a specific invitation for the main WB to activate a part in itself. Perhaps the fix should be to have requestActivation honor DW's ??
Worse than I thought...this is a result of the Shell's restoreFocus method granting focus (and activating) the last widget with focus in the shell owning the menu. In the worst scenario I can think of you'd have the Project Explorer open (and active) in the main shell and the Package Explorer detached. If you then select files "A", "B" and "C" in the Project Explorer, then select files "D", "E" and "F" in the Package Explorer then doing "Edit -> Delete" will end up deleting ABC rather than DEF as expected. Fortunately this doesn't appear to be a very common workflow, presumably most folks that use DW's don't detach the 'navigation' views but usually detach the ancillary views like Search...most of which contain their own menus etc to operate locally on their selection (i.e. not many views actually provide selections for which the main menu would be of use so users don't hit this).
I've spent some extra time on this since we have the same issue in e4. Unfortunately I'm not sure that a viable fix is even possible here... SWT: Clicking on the main shell's menu activates it (seems like correct behavior) Activating a shell restores its previous focus and ectivation Us: If a part gets activated by SWT we make it the active part. This is correct in every situation except this one (i.e. the user may just have clicked on the shell's title area to activate it in which case we want the current behavior. We have *no* way to detect that the shell going active was the result of the user selecting the main menu. I've rigged up an SWT testbed to try out various strategies but even if I can prevent the part's activation we just end up with an 'active' part that doesn't have focus and an active shell that doesn't contain the active part...confusing at best.
Created attachment 182934 [details] SWT Testbed
See also bug 346279.
This is exactly the same problem as bug 46962. The detached view should be in a palette window that doesn't deactivate the workbench window.
*** Bug 346279 has been marked as a duplicate of this bug. ***
probably the most annoying of this bug is when you're looking in a .class file (that you can see its source because it's in a jar to which you attached source) and then you want to click on Project->Properties and find that Properties is grayed out, so you have to click on the exact project(or any files in it)[even though that project is already selected] in the package explorer (not enough to just activate/focus package explorer) in order to ungray the Properties... hmm actually this seems unrelated to this bug, but I thought it's same... can anyone confirm it's unrelated?
(In reply to comment #15) > probably the most annoying of this bug is when you're looking in a .class file > (that you can see its source because it's in a jar to which you attached > source) and then you want to click on Project->Properties and find that > Properties is grayed out, so you have to click on the exact project(or any > files in it)[even though that project is already selected] in the package > explorer (not enough to just activate/focus package explorer) in order to > ungray the Properties... hmm actually this seems unrelated to this bug, but I > thought it's same... can anyone confirm it's unrelated? Yes, this is an unrelated bug. Please file a new one against JDT UI. We need to investigate whether we can register an IProject adapter on those Java elements.
*** This bug has been marked as a duplicate of bug 100909 ***
Reopening, as most of the discussion is in this bug.
.
*** Bug 100909 has been marked as a duplicate of this bug. ***
*** Bug 388066 has been marked as a duplicate of this bug. ***
At first I thought this bug were a duplicate of bug 195672, which had some different steps to repro but described the same misbehaviour about the main window main menu bar. However, while I can't reproduce bug 195672 on Eclipse Luna I20140606-1215, I can still reproduce this one by following the steps to repro in the description. So this is still valid in current Eclipse.
Confirming that this is reproducible in Kepler and Luna. This makes the detached feature unusable especially when the detached editor relies on the contributed menu/toolbar actions to function.
I just noticed that this bug is not triggered in one specif scenario (on Windows). This might give new directions to solve to issue. 1. Make sure the Outline view is visible 2. Open two editors that provide a outline view (e.g. Java editors) 3. Detach one editor 4. Activate the non-detached editor 5. Activate the Outline view 6. Activate the detached editor 7. Select a menu item (e.g. File -> Properties) or toolbar item that apply to the detached editor: It works as expected. Further observations: * If after step 6 the main window is activated, the outline does not get activated. Instead the editor in the detached window is still activated (but does not have focus). But maybe this is 'just' the active shell without active part, and active part without focus. This might seem confusing, but surely less confusing than the current behavior.
*** Bug 573530 has been marked as a duplicate of this bug. ***
