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.
When using native MAC L&F then the editor has only two tabs and all other files should be accessed via a drop down list. Unfortunatelly if I select such s file in the list then it is shortly displayed but then the editor "snaps" back to the previously edited file. So I can not edit more than two files at a time. It depends on the length of the filename when this effect happens. I can reproduce it very easily when I open files from a CVS repository because they always have some information like "Up to Date" attached to them.
Adding Tomas Hurka on the CC (our Apple expert). Tomas do you have an idea what is the problem? I did not follow the report, but reason might be that I'm no familiar with Apple UI. Anyway if there is problem like this it seem to me to be in window system which manages tabs. Moving issue there. I'm decreasing priority to P3, because this does not seems to be P1 defect. AFAIK there are users running the NB IDE on Mac OS X and they did not report serious problem like this. Tomas, if I'm wrong please increase priority accordingly. Thanx.
Which version of JDK are you using? Do you run NetBeans in SDI or MDI mode?
This happens on MAC OS X using Java 1.4.1 - I have not tried on Java 1.3.1 because it is so slow using MAC OS native L&F. It seems there is some unclarity in my first description. MAC OS X allows only a certain number of tabs in a row (there are now multi row tabs) which means that when the label of a tab - aka a Filename gets very long then the number of tabs one can have on a row gets reduced to two or even one. To access the rest of the tabs a new tab is generated behind which is a dropdown box. In this box one can select any of the open files. This behaviour can only be produced with MAC OS X native L&F. With Metal L&F I get the usual multi row tabs and everythinh works ok. May be I should forward this issue to Apple's engineering as well. Should I send a screen shot ?
You are right. I can reproduce it here too. It seems to us that this is problem with focus. There is no need for screenshot. We need more time to find out if this our or Apple fault.
We saw it here too. It seems some additional focus requests are performed. As our container implementation reacts to FOCUS_GAINED event it makes tab selection when it receives FOCUS_GAINED event for previous tab. We will try to investigate where these events come from.
This seems to me like serious problem on Mac OS X.
Assigning back to Tomas.
One problem showing here is http://developer.java.sun.com/developer/bugParade/bugs/4648816.html. (In some cases we do not receive FOCUS_GAINED event even if we called requestFocus() before. We receive FOCUS_GAINED event when we move mouse over Source Editor. It causes delayed reset of tabs in Source Editor.) Not sure if it is only problem here.
I prepared patch for this issue. It seems to be working fine, can you (mschorer@netbeans.org) please test it? Patch installation: Go to netbeans home directory and extract the tar.gz archive. It should create two files lib/patches/bug_32655.jar modules/patches/org-netbeans-modules-java/bug_32655.jar
Created attachment 9813 [details] Binary patch
Created attachment 9814 [details] Diff for core
Created attachment 9815 [details] Diff for java module
Created attachment 9826 [details] ide.log
I have tried the proposed patch, but it makes my ide crash. See attached ide.log
The problem is caused by changes in code between NB 3.4.1 and current version (dev or release35). Please test last Q-build.
Or daily build of release 3.5 at http://www.netbeans.org/devhome/download.html.
Marek is right. I am sorry, I forgot to mention that the patch is for NetBeans 3.5.
I have tried the proposed patch from Tomas with the daily build 3.5 and it works perfect !!!!! Thanks a lot
The Java 1.4.1 Swing from Apple seems to have dreadful problems with this Tab view. When I use Netbeans with more than a few source files open (ie. enough to cause the tab view to create this horrible pop-up menu to replace the tabs) it becomes unworkable - besides the problem of "snapping back" to other open editors the tabs seem to randomly rearrange themselves when a new one is selected, the little "close" crosses for the tabs get drawn in weird places even though the tabs themselves are hidden (ie. they're in the popup) and the behaiour of the pop-up menu is arbitrary at best - ie. when some tabs are closed it often waits until only one is left before relinquishing control and displaying tabs again (instead of the popup). at least it doesn't crash any more - it used to produce a low level crash which causes the app to quit. I have filed several bug reports about this with Apple - it might help if others also added their weight.
I had thought that the problem here was with Apple's Tab view (and it certainly seems to be a bit flaky), but I've just checked out IntelliJ IDEA, which has a similar Tab view and it seems to work fine. Maybe it's the little "close" crosses that netbeans adds to the Tabs ?
Joshua, It has nothing to do with those little "close" crosses. See attached patches for the fixes.
Fixed in SplitContainerImpl.java in trunk. Checking in SplitContainerImpl.java; /cvs/core/src/org/netbeans/core/windows/frames/SplitContainerImpl.java,v <-- SplitContainerImpl.java new revision: 1.105; previous revision: 1.104 done The root of this bug is caused by the fact that requestFocus() is asynchronous, while setSelectedTopComponent() is synchronous. The scenario when user selects new tab using drop down list is as follow: (Suppose the old tab is A and new tab is B and that tab A has focus.) 1) User opens drop down list implemented by JMenu 2) New window with drop down list is created. 3) Component with current focus (A) is recorded by JMenu 4) User selects component B from drop down list. 5) JMenu sends requestFocus() to last focused component, which is A 6) Component B is selected immediately by setSelectedTopComponent() 7) Component A is selected, since requestFocus() is asynchronous The fix uses requestFocus() instead of setSelectedTopComponent(). This way both actions in steps 5 and 6 are asynchronous.
Petr Felenda, can you verify this issue. Thanx
I try it to reproduce on the reported 341 build and the dev build (20040224), but there is a new window system in dev builds. I can mention that it is not possible reproduce it on dev. It is possible switch between tabs. Verified -> it works correctly.