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.
Product Version = NetBeans IDE Dev (Build 200211270100) IDE Versioning = IDE/1 spec=3.22 impl=200211270100 Operating System = Linux version 2.4.18 running on i386 Java; VM; Vendor = 1.4.1_01; Java HotSpot(TM) Client VM 1.4.1_01-b01; Sun Microsystems Inc. Java Home = /usr/java/j2sdk1.4/sun/jdk1.4.1_01/jre System Locale; Encod. = cs_CZ; ISO-8859-2 Home Dir; Current Dir = /home.local/danielm; /DISKS/storage3/forte/NBdev-last/netbeans/bin IDE Install; User Dir = /home.local/danielm/NBdev-last; /home.local/danielm/.netbeans/dev ------------------------------------------------------------------------------- I tried those 2 wizards: -update Wizard -Mounting JavaCVS Wizard And bouth have different types of windows probles: Update Wizard ============= Invoke it, choose update from local NBM files and press next. The folowing panel is incredibly "tall/high" and you spend sometime by resizing it to reach the bottom of form:-((( See attached pics... CVS Mounting Wizard: ===================== All its panes illogicaly have scrollbars (at least vertical) And for one of them it might be a real problem: eg. select Relative MountPoint... see also another pics...
Created attachment 8068 [details] CVS Mounting Wizard
Created attachment 8069 [details] Update Wizard
Created attachment 8070 [details] Update Wizard
I'm very sorry... me & Jirka've just found that this happens only with jdk1.4.2-b08 so probably this bug is irelevant... at least loverising priority to P4...if you think, close it...
It's reproducible on [jdk1.4.2](07) too. Steps to reproduce: - run IDE - push from menu Versioning | Mount Version Control | CVS - select nb_all/core in browse dialog - push Next - push Back, push Back -> Mount Wizard pane contains sliders !
:-O oups... Sorry for confusing you:-/ I wanted to say: There's no problem using jdk1.4.1 (exacly I'm using 1.4.1_01) But problem is with jdk1.4.2 (and I've only ever tried b08) and because jdk1.4.2 is not finished yet I think the bug can't be P2..
Dan is right, P2 -> P4 It is really reproducible only on Mantis , I have tried 07 and 08.
*** Issue 29113 has been marked as a duplicate of this issue. ***
*** Issue 29268 has been marked as a duplicate of this issue. ***
Version changed: 4.0 dev -> S1S 4.2
IMHO this is a real usability problem for Mantis users (I saw it on b10), and we need to make sure when Mantis is released that NB runs smoothly on it.
*** Issue 30091 has been marked as a duplicate of this issue. ***
Works fine with JDK142b13 - Jirko I think this issue should be set as closed now.
Jara, I have tried the same build [jdk1.4.2](b12) and it is still reproducible there.
Confirmed with JDK 1.4.2 build #13. Why should it be closed ?
I have the problem again with JDK 1.4.2 - build #15. I agree that this issue should remain opened.
It must be investigate ASAP, optionally file a jdk142 bug.
Jirka, it's very annoying issue, I am rising priority only to be sure it will be evaluated before development complete (and don't forget :).
Going to help with this one.
First, how to easily reproduce it. I'm running: NetBeans IDE Dev (Build 030224) IDE/1 spec=3.39 impl=030224 Windows 2000 version 5.0 running on x86 1.4.2-beta; Java HotSpot(TM) Client VM 1.4.2-beta-b16; cs_CZ; Cp1250 and there are two options: 1.) Tools -> Update Center -> select "Install Manually Downloaded Modules" and press Next. The dialog will be extremely tall 2.) Versioning -> Mount Version Control -> CVS -> press Back. The dialog will have scroll bars. This is regression caused by the fix of JDK issue 4410243 (<http://developer.java.sun.com/developer/bugParade/bugs/4410243.html>). This problem was fixed in the file javax.swing.text.WrappedPlainView. You can search the file for the issue number. The problem is obvious just from the source code diff of 1.4.1_01 and 1.4.2b16: @@ -521,13 +523,17 @@ final int calculateLineCount() { int nlines = 0; int p1 = getEndOffset(); for (int p0 = getStartOffset(); p0 < p1; ) { nlines += 1; int p = calculateBreakPosition(p0, p1); - p0 = (p == p0) ? p1 : p; + p0 = (p == p0) ? ++p : p; + // this is the fix of #4410243 + // we check on situation when + // width is too small and + // break position is calculated + // incorrect } return nlines; } If calculateBreakPosition() does not calculate any break position for the text, the p0 is incremented by one and calculation is started on the next character. That also means that nlines will end up with value equal to the number of characters in the text. And that's the problem. This value is used for calculation of prefered height of the component and the return value will be extremelly high. Revert of the fix solved all the problems. I'm going to report this to bugtraq.
I'm evaluating possibility to workaround it. I have an idea.
Created attachment 9131 [details] simple java program demonstrating this defect. see comments in the file
Possible workaround is to use getPreferredSize() instead of getMinimumSize() in case the minimum size is larger than preferred size. This could be checked in NbPresenter and it works. But any code using the getMinimumSize() will still fail, means we might workaround the most of the problems but not all.
Well, I have reported regression as bug to bugtraq for JDK1.4.2(build16). Bug should be find : http://developer.java.sun.com/developer/bugParade/bugs/4824261.html I suppose let this issue opened and ask for waiver, than we can wait for fix for mantis. If not we can apply some workarround.
> I suppose let this issue opened and ask for waiver, than we can wait > for fix for mantis. If not we can apply some workarround. as dkonecny indicated it's messy to implement a workaround on our side. We'd rather make sure the bug will be fixed on the JDK side.
Justification of WAIVER request: This problem is caused by the regression in JDK 1.4.2. So I'm asking for waiver and hope that problem will be fixed in JDK. It is filed as bugtraq issue 4824261. It could be workarounded in NB, but problem is that there is not single place for workaround - the whole codebase would have to be searched and found places would have to be fixed individually. It is risky and 100% fix cannot be guaranteed. This JDK problem will be also visible when older versions of S1S are started on it.
Still does not work in Beta18.
Confirmed, still happens in b18.
AFAICT the fix did not make into b18 on time. Wait for b19
Confirmed OK in Mantis b19.
dkonecny, please verify and if it works for you too, then close this bug. thx
Can someone please verify this bug w/ Mantis b19 on Solaris and Windows and close it? Thanks
I cannot do that. The Win installer of beta19 fails on my comp with error reported as bugtraq issue 4838604 which was closed as not-a-bug. But it still failing for me and I cannot install it. I can only wait for next build. The potential problem could be that I'm low on free disk space on C: drive, but I could not install jdk on D: drive! In short, I give up and will wait for next build. Jesse verified it. Marian, could you please try it on Solaris and close this issue if it works there? Thanx.
Should I keep this as a release note, even if it is confirmed fixed in b19? If so, would the following text suffice: "Some windows are improperly sized when running the IDE on beta versions of the J2SE SDK, v. 1.4.2."
It works fine with [jdk1.4.2](b 19) on Solaris 8, CDE, [nb3.5](200304012350).
Marian told me that he will try it on his Win machine tomorrow. Patrick, it is not necessary to keep it. I would simple remove it from rel notes. I think that JDK betas are not publicly available; anyway it will be fixed in newer betas.
Yes, should not be of concern to users; the affected 1.4.2 builds are not publically available.
Ok, I am closing this one as WONTFIX, because this issue will never be visible for users.
Verified on W2000! The Win installation requires much more free space then installer asks for although the resulting installation is of half size.
NB3.5 fcs works fine fith Mantis fcs on all platform (at least if we talk about this problem) so thus verifying