This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Start NetBeans with JDK 1.4 & windows look and feel. This means that when there are multi-line tab rows, clicking a tab in the bottom row will swap positions of the two rows of tabs - the row containing the open component is always closest to the interior of the JTabbedPane. To reproduce: - Open enough files in the editor that you have two rows of tabs. - Right click one of the tabs on the bottom row, planning to close it. The following sequence of events happens: -- The tab rows change - the bottom row is now the top row -- The context menu appears with the Close menu item for the tab the mouse is now over, on the new bottom row -- When you click Close on the context menu, you are closing the tab that is now on the bottom row, not the one you wanted to close A fairly simple solution to this would be to set up Modes so that right clicking a tab does not select that tab - this is a problem anyway, since if the only reason someone brings up the tab context menu is to close a tab, they probably do not want to display it (and on machines with low memory, wait for the swapping reqired to pull it out of virtual memory when the only purpose is to close it).
x
Tim, this is "as designed". Right-click servers two purposes: 1) it selects the component under the mouse pointer, if not already selected 2) it shows the popup menu which contains action for the (newly) selected component Not doing 1) creates a lot of UI problems I believe. Marking this bug as INVALID.
I don't want to get in an argument here, but I can't believe that right-clicking one component and having the context menu for a different component pop up is "as designed." Probably the best idea in this case is to disable tab row position swapping in the Windows L&F (tab row swapping is pretty non-intuitive anyway) or disable foregrounding a tabbed pane on a right click (on a slow machine it's annoying to have to redisplay a file when you just want to close it, although close buttons on editor tabs eliminates this problem). Just to clarify, the specific problem is that if I have tabs like: |___File 1____| |____File 2_____| and I right click the tab for File 2, the tab positions switch and I get a context menu for File 1. So I think I am closing File 2 if I choose Close, but what gets closed is File 1. The problem is the order of operations.
> Just to clarify, the specific problem is that if I have tabs like: > > |___File 1____| > |____File 2_____| > > and I right click the tab for File 2, the tab positions switch and I > get a context menu for File 1. I see. The root of this trouble is that - tab switch happens on mouse press - then the tab positions switch - then the popup is displayed because it happens on mouse release but now of course the mouse pointer is on a different tab What do you, Tim, suggest? Could you bring it to nbui?
Actually, I'm on vacation until June 7, and I'm only in the office because I need to print the book - so I won't have access to nbui regularly until then. I'd guess you can turn off tab row flipping. That's what I'd suggest as a fix. It's generally counter-intuitive anyway. The argument will no-doubt be that it breaks the platform emulation (note metouia l&f also does tab row flipping). I'll bring it up on nbui, but somebody else will need to drive the conversation.
-> ttran
fixed in trunk by always invoking the popup on mouse-pressed event, completely ignoring MouseEvent.isPopupTrigger()
issue doesn't apply to new window system - verified