Bugzilla – Full Text Bug Listing
| Summary: | [EditorMgmt] Middle click to close tab switches editor before close | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Andrew Niefer <aniefer> | ||||||
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||||
| Status: | RESOLVED WORKSFORME | QA Contact: | Remy Suen <remy.suen> | ||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | eclipse.felipe, emoffatt, markus.kell.r, remy.suen | ||||||
| Version: | 3.5 | Keywords: | helpwanted | ||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 258727 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Andrew Niefer
Yeah, I'd like to see this too. The same applies to views, and what's really bad is that if I want to close a view that I haven't used or brought to the front in the current session, it will first be materialized (activating plugins etc...) before it will be closed. For referencing purposes, this is very much related to bug 60833. Upon investigation, SWT will need to "ignore" secondary mouse clicks on unselected tab items for this to be possible. Please see bug 258727. This works for me on 3.5 M5. Modern mouses configure the middle click (or clicking on the wheel) to some functions specific to mouse (free spinning mode, zoom, flip window, etc). Application shouldn't use middle click anymore. (In reply to comment #4) > This works for me on 3.5 M5. Clicking on the mouse wheel works for me on I20090203-1200. Andrew? > (In reply to comment #4)
> > This works for me on 3.5 M5.
> Clicking on the mouse wheel works for me on I20090203-1200. Andrew?
Can you please run Snippet62.java from org.eclipse.swt.snippets.
what does it print to the console when you click on the wheel ?
(In reply to comment #6) > Can you please run Snippet62.java from org.eclipse.swt.snippets. > what does it print to the console when you click on the wheel ? Your wish is my command. DOWN: button: 2, stateMask=0x0, x=29, y=10 UP: button: 2, stateMask=0x100000, x=29, y=10 BUTTON2 DOWN: button: 2, stateMask=0x0, x=29, y=10 UP: button: 2, stateMask=0x100000, x=29, y=10 BUTTON2 DOWN: button: 2, stateMask=0x0, x=29, y=10 UP: button: 2, stateMask=0x100000, x=29, y=10 BUTTON2 DOWN: button: 2, stateMask=0x0, x=29, y=10 UP: button: 2, stateMask=0x100000, x=29, y=10 BUTTON2 Thanks. I see, we copied this behaviour from IE and Firefox. This is probably a side effect of Bug 60833, workbench should only switch tab when button==1. In M5 I'm still seeing a tab switch before close, both in editors and in views. This is a wheel click on my logitech mouse, and the same for the middle bottom above the trackpad on my thinkpad. If it helps anything, I tried a spy and see WM_MBUTTONDOWN wparam=0x00000010 lparam=0x0007001b WM_MBUTTONUP wParam=0x00000000 lParam=0x0007001b I'll try the Snippet62 My Snippet62 on wheel click is the same as Remy's Created attachment 124900 [details] Activate part only on first mouse click patch v1 (In reply to comment #8) > Thanks. I see, we copied this behaviour from IE and Firefox. > This is probably a side effect of Bug 60833, workbench should only switch tab > when button==1. (In reply to comment #9) > In M5 I'm still seeing a tab switch before close, both in editors and in views. Thank you Andrew and Felipe for your input. Does your patch fixes Bug 60833 ? (In reply to comment #12) > Does your patch fixes Bug 60833 ? No, that includes changes that doesn't affect the middle click. I will provide details on that bug. Remy, the patch is simple and -appears- to have no regressive effects (as well as fixing the activation issue). The context menu still activates the part when it is shown but as discussed in this morning's meeting that's likely OK. I've been tracing through the code and still can't figure out how the right click handling sends the same event "EVENT_GIVE_FOCUS_TO_PART" but doesn't end up activating the part (it's actually activated as part of showing the context menu) but that's OK, there are many parts of the event cascades that I don't understand...;-) (In reply to comment #14) > I've been tracing through the code and still can't figure out how the right > click handling sends the same event "EVENT_GIVE_FOCUS_TO_PART" but doesn't end > up activating the part (it's actually activated as part of showing the context > menu) but that's OK, there are many parts of the event cascades that I don't > understand...;-) Since the part has been activated when the context menu was brought up, the WorkbenchPage class simply returns. Is this what you are talking about? private void setActivePart(IWorkbenchPart newPart) { // Optimize it. if (getActivePart() == newPart) { return; } /* ... */ } Created attachment 125958 [details] Activate part only on first mouse click patch v2 Problem with attachment 124900 [details]: 1. Click on one view in one view stack to activate it. 2. Click on another view in another view stack to activate it. 3. Bring up the context menu on the first view's view tab. 4. The view will _not_ get the blue outline but stays white. Thanks Remy, I was looking at this when I got side swiped by the CPD issues...I'll get back to it tomorrow. Apr 24 10:14:27 * borisb6i1 is sniping views using the middle mouse button Apr 24 10:14:55 <borisb6i1> Thanks rcjsuen for fixing this! Apr 24 10:15:11 <rcjsuen> borisb6i1: what, that's not committed yet Apr 24 10:15:15 <rcjsuen> at least, Idon't think it is Apr 24 10:15:30 <rcjsuen> unless Eric pushed it without telling me Guess we all forgot about this bug. Sorry Remy, I didn't tag it. Boris this looks simple/safe enough for inclusion in RC1, any objections? Doesn't look safe as is (because it also affects the right mouse button), but I just tested on Win32 and the middle click no longer activates editors or views before closing them. Something else must have changed between 3.4 and 3.5. I have not had much luck getting the debugger to stop when I place breakpoints in createPartControl or the one in WorkbenchPart's constructor. Thus, it seems classes are no longer being loaded (which would imply that bundles are not being eagerly activated). From a preliminary investigation, one behaviour that this patch _will_ change is the following: 1. Have two parts, A in front and B behind, in one stack. 2. Have the active part (C) in another stack. 3. Middle-click on the hidden part B from step 1. 4. Focus/Blue outline transfers from C to A. With the patch, the focus stays on C. This seems rather trivial and insignificant by comparison in my opinion so I would support deferring to 3.6. +1 for leaving until 3.6...I have a number of defects that only occur when the editor area is split so this area could use a close look overall in 3.6... BTW, the transfer of the stack's focus is likely caused by the stack itself trapping the SWT.Activate event (to allow clicking inside a view to activate it) so this artifact may be difficult to fix cleanly... (In reply to comment #22) > +1 for leaving until 3.6...I have a number of defects that only occur when the > editor area is split so this area could use a close look overall in 3.6... Also, I just checked and middle-clicking no longer activates before close, on Win32 and Linux GTK. Not sure how you can middle-click on a Mac :-/ Remy is now responsible for watching the [EditorMgmt] component area. Andrew, do you still see this problem on 3.6? I cannot observe the described behaviour on I20091118-1342 (unless it is switching/closing really fast). (In reply to comment #0) > Note that if I middle click but don't release right away, then I get a switch > to that tab, but the tab doesn't close. I don't see this. For me, if I hold it down a bit (or a lot) and then release, it is a no-op. My active editor does not change and the hovered-over editor is _not_ closed. (In reply to comment #26) > Andrew, do you still see this problem on 3.6? I cannot observe the described > behaviour on I20091118-1342 (unless it is switching/closing really fast). > > (In reply to comment #0) > > Note that if I middle click but don't release right away, then I get a switch > > to that tab, but the tab doesn't close. > > I don't see this. For me, if I hold it down a bit (or a lot) and then release, > it is a no-op. My active editor does not change and the hovered-over editor is > _not_ closed. Sorry I missed this before Remy, with recent IBuilds I no longer see the switch before close. As well, holding down the click is also a no-op. The only thing I notice is that if I am closing a number of editors this way (middle clicking on tabs), if I go too quickly then sometimes nothing happens on the click. Likely the event is getting swallowed as a double-click... Is this an issue in E4? For me clicking the close on a non-active part doesn't appear to activate it... Works for me in I20121113-0800 and 3.8 on Windows 7. Right-click still activates the part (bug 60833), but that's OK for me. |