Community
Participate
Working Groups
M5: When debugging I was surprised to hit some of my breakpoints when cleaning up the workspace by closing some inactive editors. On investigation it seems that the active editor is re-activated causing a potentially buggy editor to do a lot of unnecessary work. Buggy or not, surely clicking on the close tab of an inactive, indeed never active, editor should do very little.
I set a breakpoint in the EPartService#showPart and it doesn't hit when I close another editor which is not the active one. Maybe I am misunderstanding what you mean with 're-activated'. Can you provide a bit more detail on where you set the breakpoints so that you think it's reactivated? I'm on I20130402-0800.
Sorry. It has been fairly clear from the number of Bugzillas I've come across/reported involving 'activation' that this is a disaster area in e4, so as soon as I hit this area. I just sign, oh yet another one, and move on. I can only observe that showPart is not activate. I was encountering unexpected handleActivation or similar listener call back in an editor that misbehaved (not due to e4) and so revealed its redundant 're-activation'.
I noticed, that when an Eclipse window is being activated, all the open editors have there respective Parts activated, even those that are not on top. I don't think that's right. The editor on top is activated last.
Although I am not observing the editor being activated when it is being closed. Scenario: 1. set up a breakpoint in AbstractTextEditor$ActivationListener.handleActivation 2. in the debugging session, open two java files - top.java and bottom.java 3. close the editor with bottom.java (inactive editor) The breakpoint is not hit. Ed, can you please let me know if this scenario is similar to yours, otherwise, can you clarify what your scenario is?
(In reply to comment #4) > Ed, can you please let me know if this scenario is similar to yours, > otherwise, can you clarify what your scenario is? I have seen so many problems with part activation that I've given up reporting them. There must be more than enough in existing Bugzillas for a proper analysis and design of how e4 will reproduce the distinct 3.x editor/view behaviour.
Already fixed, putting a BP onto PartServiceImpl#activate does fire when you close a non-active editor...
Verified in 4.4.0.I20131001-0800.
(In reply to Eric Moffatt from comment #6) > Already fixed, putting a BP onto PartServiceImpl#activate does fire when you > close a non-active editor... ?? missing "not" ??
This is not fixed and should be reopened. I don't think Eric understood the problem. To reiterate, consider two open editors, E1 and E2, in the same editor area. E2 is active. Click on the close button of E1. This action causes activation of E1 even though it will close subsequently under normal circumstances. The close prompts the reactivation of E2. These activations may cause the UI to convulse quite a bit, seemingly unnecessarily. This bug appears to be intractable. First we get the E1 activate event… PartServiceImpl.activate(MPart, boolean, boolean) line: 689 PartServiceImpl.activate(MPart, boolean) line: 620 DSStackRenderer(AbstractPartRenderer).activate(MPart) line: 106 StackRenderer$9.handleEvent(Event) line: 1013 EventTable.sendEvent(Event) line: 84 Display.sendEvent(EventTable, Event) line: 4353 CTabFolder(Widget).sendEvent(Event) line: 1061 CTabFolder(Widget).sendEvent(int, Event, boolean) line: 1085 CTabFolder(Widget).sendEvent(int, Event) line: 1070 Shell.setActiveControl(Control, int) line: 1453 Shell.WM_MOUSEACTIVATE(long, long) line: 2334 Shell(Control).windowProc(long, int, long, long) line: 4654 … long series of windowProc dispatching omitted CTabFolder(Control).windowProc(long, int, long, long) line: 4705 Display.windowProc(long, long, long, long) line: 5036 OS.PeekMessageW(MSG, long, int, int, int) line: not available [native method] OS.PeekMessage(MSG, long, int, int, int) line: 3141 [b]Display.readAndDispatch() line: 3756[/b] At this point the Display eventQueue is empty … and then the close … PartServiceImpl.savePart(MPart, boolean) line: 1333 DSStackRenderer(StackRenderer).closePart(Widget, boolean) line: 1217 StackRenderer.access$3(StackRenderer, Widget, boolean) line: 1200 StackRenderer$12.close(CTabFolderEvent) line: 1092 CTabFolder.onMouse(Event) line: 1874 Button press event CTabFolder$1.handleEvent(Event) line: 288 EventTable.sendEvent(Event) line: 84 Display.sendEvent(EventTable, Event) line: 4353 CTabFolder(Widget).sendEvent(Event) line: 1061 Display.runDeferredEvents() line: 4172 [b]Display.readAndDispatch() line: 3761[/b] The activate event is processed fully before the button event that closes E1 is ever created and placed into the Display eventQueue… Display.postEvent(Event) line: 3710 Button press event added to eventQueue CTabFolder(Widget).sendEvent(int, Event, boolean) line: 1087 CTabFolder(Widget).postEvent(int, Event) line: 790 CTabFolder(Widget).sendMouseEvent(int, int, int, int, boolean, long, int, long, long) line: 1135 CTabFolder(Widget).wmLButtonDown(long, long, long) line: 2013 CTabFolder(Control).WM_LBUTTONDOWN(long, long) line: 4991 CTabFolder(Composite).WM_LBUTTONDOWN(long, long) line: 1372 CTabFolder(Control).windowProc(long, int, long, long) line: 4646 Display.windowProc(long, long, long, long) line: 5036 OS.DispatchMessageW(MSG) line: not available [native method] OS.DispatchMessage(MSG) line: 2549 [b]Display.readAndDispatch() line: 3759[/b]
The only practical way to omit the activation would be for StackRenderer SWT.Activate listener $9.handleEvent to check CTabItem.closeRect.contains(event.x,event.y) and omit the activate invocation when it is true. Unfortunately, StackRenderer cannot access CTabItem.closeRect.contains(event.x,event.y) The best it can do is examine the CTabFolder or CTabItem toolTipText and check that it is equal to “Close” and infer it… Not an ideal solution and may not be very robust. Even if StackRenderer could omit the activation, how many applications count on the closing editor also being the active editor?
It's worthy of mentioning that if the editors are in the same CTabFolder then there is no activation. To be consistent, either there should always be an activation before closing or the activation must never occur. I favor the latter. I would judge that Ed and most others do too.
(In reply to darrel karisch from comment #11) > I favor the latter. I would judge that Ed and most others do too. Indeed though I wonder how this relates to the general maliase: A GIT branch change starts a rebuild for every project as it changes. Close all projects takes a really long time. Type hierarchy recomputes when invisible ... There seems to be much too much reacting to a change without an overall ability to block up multiple changes as a single composite change that will complete before corrolaries occur.
(In reply to darrel karisch from comment #10) > The only practical way to omit the activation would be for StackRenderer > SWT.Activate listener $9.handleEvent to check > CTabItem.closeRect.contains(event.x,event.y) and omit the activate > invocation when it is true. > > Unfortunately, StackRenderer cannot access > CTabItem.closeRect.contains(event.x,event.y) > > The best it can do is examine the CTabFolder or CTabItem toolTipText and > check that it is equal to “Close” and infer it… Not an ideal solution and > may not be very robust. > This kludgy little modification to org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer SWT.Activate listener prevents the activation invocation when a Close is imminent ... public void handleEvent(org.eclipse.swt.widgets.Event event) { if (event.detail == SWT.MouseDown) { CTabFolder ctf = (CTabFolder) event.widget; if (ctf.getSelection() == null || SWT.getMessage("SWT_Close").equals(ctf.getToolTipText())) { return; } // get the item under the cursor CTabItem overItem = ctf.getItem(event.display.map(null, ctf, event.display.getCursorLocation())); // If the item we're over is *not* the current one do // nothing (it'll get activated when the tab changes) if (overItem == null || overItem == ctf.getSelection()) { MUIElement uiElement = (MUIElement) ctf.getSelection().getData(OWNING_ME); if (uiElement instanceof MPlaceholder) { uiElement = ((MPlaceholder) uiElement).getRef(); } if (uiElement instanceof MPart) { activate((MPart) uiElement); } } } }
(In reply to Ed Willink from comment #12) > Indeed though I wonder how this relates to the general maliase: > > A GIT branch change starts a rebuild for every project as it changes. > > Close all projects takes a really long time. > > Type hierarchy recomputes when invisible > > ... > > There seems to be much too much reacting to a change without an overall > ability to block up multiple changes as a single composite change that will > complete before corrolaries occur. https://bugs.eclipse.org/bugs/show_bug.cgi?id=443236 I'd guess that "Close All" causes PartServiceImpl::hidePart invocation at some point. PartServiceImpl::hidePart selects a sibling part when the input MPart is the selected element.
The problem is that the CTabFolder has a mouseUp event still pending after the CTabFolder's close-event is fired. The mouseUp event treats the mouseUp as if it were a normal click on the CTabItem and sets focus to the CTabItem's control.
(In reply to Brian de Alwis from comment #15) > The problem is that the CTabFolder has a mouseUp event still pending after > the CTabFolder's close-event is fired. The mouseUp event treats the mouseUp > as if it were a normal click on the CTabItem and sets focus to the > CTabItem's control. with org.eclipse.swt.win32.win32.x86_64_3.103.2.v20150203-1351.jar I do not see where CTabFolder MouseUp event handling sets focus on the CTabItem. The code I see only acts to close the CTabItem when the event occurs within its closeRect, i.e. item.closeRect.contains(x,y) is true.
(In reply to darrel karisch from comment #16) > (In reply to Brian de Alwis from comment #15) > > The problem is that the CTabFolder has a mouseUp event still pending after > > the CTabFolder's close-event is fired. The mouseUp event treats the mouseUp > > as if it were a normal click on the CTabItem and sets focus to the > > CTabItem's control. > > with org.eclipse.swt.win32.win32.x86_64_3.103.2.v20150203-1351.jar > > I do not see where CTabFolder MouseUp event handling sets focus on the > CTabItem. > The code I see only acts to close the CTabItem when the event occurs within > its closeRect, i.e. item.closeRect.contains(x,y) is true. My mistake. You are referring to StackRenderer. Its mouseUp behaves as you describe.
(In reply to Brian de Alwis from comment #15) > The problem is that the CTabFolder has a mouseUp event still pending after > the CTabFolder's close-event is fired. The mouseUp event treats the mouseUp > as if it were a normal click on the CTabItem and sets focus to the > CTabItem's control. In this case, one of the remaining CTabItem control's is focused and activated. The result being that a new part is activated, rather than the original active part in another CTabFolder. Only the case where the CTabFolder has no other remaining tabs do we end up with the original part remaining active. Nevertheless, omitting the activation of the closing part is an improvement.
Ed and/or Brian, can you check whether this is still an issue? Thanks.
(In reply to Dani Megert from comment #19) > Ed and/or Brian, can you check whether this is still an issue? Thanks. Bug 528724 was identified as the ATL debugger affecting other debuggers. This may have been the cause of some observations. Since the ATL fix is not properly available yet, I'm unsure whether what I still see is ATL related. There are certainly a number of poor view refreshes in the Variables View. I suggest closing with an invitation to raise a new bug with a new repro.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
The history clearly shows reproducibility, fixes and evolution,. Therefore definitely not WONTFIX ... FIXED pending a REOPEN for further repro.
